MySQL Proxy工作机制浅析
MySQL Proxy处于客户端应用程序和MySQL服务器之间，通过截断、改变并转发客户端和后端数据库之间的通信来实现其功能，这和WinGate之类的网络代理服务器的基本思想是一样的。代理服务器是和TCP/IP协议打交道，而要理解MySQL Proxy的工作机制，同样要清楚MySQL客户端和服务器之间的通信协议，MySQL Protocol包括认证和查询两个基本过程：
认证过程包括：
- 客户端向服务器发起连接请求
- 服务器向客户端发送握手信息
- 客户端向服务器发送认证请求
- 服务器向客户端发送认证结果
如果认证通过，则进入查询过程：
- 客户端向服务器发起查询请求
- 服务器向客户端返回查询结果
当然，这只是一个粗略的描述，每个过程中发送的包都是有固定格式的，想详细了解MySQL Protocol的同学，可以去这里看看。MySQL Proxy要做的，就是介入协议的各个过程。首先MySQL Proxy以服务器的身份接受客户端请求，根据配置对这些请求进行分析处理，然后以客户端的身份转发给相应的后端数据库服务器，再接受服务器的信息，返回给客户端。所以MySQL Proxy需要同时实现客户端和服务器的协议。由于要对客户端发送过来的SQL语句进行分析，还需要包含一个SQL解析器。可以说MySQL Proxy相当于一个轻量级的MySQL了，实际上，MySQL Proxy的admin server是可以接受SQL来查询状态信息的。
MySQL Proxy通过lua脚本来控制连接转发的机制。主要的函数都是配合MySQL Protocol各个过程的，这一点从函数名上就能看出来：
- connect_server()
- read_handshake()
- read_auth()
- read_auth_result()
- read_query()
- read_query_result()
至于为什么采用lua脚本语言，我想这是因为MySQL Proxy中采用了wormhole存储引擎的关系吧，这个虫洞存储引擎很有意思，数据的存储格式就是一段lua脚本，真是创意无限啊。
使用MySQL Proxy和MySQL Replication实现读写分离
MySQL Replication可以将master的数据复制分布到多个slave上，然后可以利用slave来分担master的读压力。那么对于前台应用来说，就要考虑如何将读的压力分布到多个slave上。如果每个应用都需要来实现读写分离的算法，一则成本太高，二来如果slave增加更多的机器，应用就要随之修改。明显的，如果在应用和数据库间加一个专门用于实现读写分离的中间层，则整个系统的架构拥有更好的扩展性。MySQL Proxy就是这么一个中间层代理，简单的说，MySQL Proxy就是一个连接池，负责将前台应用的连接请求转发给后台的数据库，并且通过使用lua脚本，可以实现复杂的连接控制和过滤，从而实现读写分离和负载平衡。对于应用来说，MySQL Proxy是完全透明的，应用则只需要连接到MySQL Proxy的监听端口即可。当然，这样proxy机器可能成为单点失效，但完全可以使用多个proxy机器做为冗余，在应用服务器的连接池配置中配置到多个proxy的连接参数即可。
MySQL InnoDB存储引擎的事务隔离级别
我们知道，在关系数据库标准中有四个事务隔离级别：
- 未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据
- 提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别
- 可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读
- 串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞
查看InnoDB系统级别的事务隔离级别：
+-----------------------+
| @@global.tx_isolation |
+-----------------------+
| REPEATABLE-READ |
+-----------------------+
1 row in set (0.00 sec)
查看InnoDB会话级别的事务隔离级别：
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set (0.00 sec)
修改事务隔离级别：
Query OK, 0 rows affected (0.00 sec)
mysql> set session transaction isolation level read committed;
Query OK, 0 rows affected (0.00 sec)
MySQL InnoDB存储引擎的一些参数
InnoDB做为MySQL目前最广泛的事务存储引擎，很多地方的设计和Oracle都是共通的。对于Oracle DBA来说，学习的时候可以多和Oracle的一些特性进行类比，当然也要明白二者之间的区别。
innodb_additional_mem_pool_size
用于缓存InnoDB数据字典及其他内部结构的内存池大小，类似于Oracle的library cache。这不是一个强制参数，可以被突破。
innodb_buffer_pool_size
内存缓冲池大小，用于缓存表和索引数据等。类似于Oracle的buffer cache，如果可能，尽可能的设置大一点。
innodb_log_buffer_size
日志缓冲区大小，类似于Oracle的log buffer
innodb_log_file_size
日志文件大小。默认会创建2个5M大小的名为ib_logfile0和ib_logfile1的文件。日志文件的数目由参数innodb_log_files_in_group指定。存放位置由innodb_log_group_home_dir指定。
innodb_data_file_path
指定InnoDB表空间数据文件名，大小以及其他属性。所有文件的加起来不能少于10M。多个数据文件之间以逗号分割，属性之间以冒号分割。默认创建一个大小10MB名为ibdata1的可自动扩展的数据文件，一般在生产环境中都需要根据实际情况指定，由于往表空间中添加数据文件需要停机，尽量在规划的时候做好准备，如果可以的话最好开启最后一个数据文件的自动增长属性。数据文件的个数在规划的时候还需要考虑另外一个innodb_open_files参数。
innodb_file_per_table
取值为ON或者OFF。是否为每个table使用单独的数据文件保存。如果系统中表的个数不多，并且没有超大表，使用该参数可以使得各个表之间的维护相对独立，有一定的好处。
innodb_autoextend_increment
当自动扩展表空间被填满之时，每次扩展空间的大小，默认值是8(单位MB)。该参数可以动态修改：
Query OK, 0 rows affected (0.01 sec)
innodb_status_file
定期将show inndb status的结果输出保存到文件中，建议开启以便分析性能。
