MySQL主从服务器的一些技巧

fatrabbit

问题：主从服务器表类型的选择

一般的共识是主服务器使用innodb，事务，行锁等功能是myisam所没有的，对修改操作而言，它更高效；从服务器使用myisam，全文检索功能是innodb所没有的，对查询操作而言，它更高效。这样就可以各尽其能。

问题：主从服务器字段类型的选择

字段类型对于分页等操作有很大影响。主服务器一般是innodb，因为不涉及查询，所以可以使用varchar等来存储字符串来节省空间，从服务器一般是 myisam，因为涉及查询，所以必须在char和varchar之间仔细权衡，没有varchar, text, blob字段的表是静态表，反之是动态表，静态表的检索效率要比动态表好若干倍，一般来说，所有涉及大结果集的查询都应该尽可能保证在静态表上完成，这里 说一个例子：比如说常见的articles表有title(varchar), body(text)等字段，在做文章列表的时候，因为不是静态表，所以查询不会很快，下面开始重构解决方案：把原来的articles表拆分成 subjects表和contents表，title字段设置为一个足够的char类型放在subjects表里，body字段还保持是text类型放到 contents表里，subjects和contents表之间的关系是一对多，这样，顺带着也方便的实现了多页文章的功能，而且更重要的是在查询文章 列表的时候，操作都是在subjects静态表里完成，效率肯定会比前一种方案提升很多。

强调：MyISAM里静态表和动态表的区别对性能影响极大，但我敢说很大一部分使用者并没有注意过这一点！如果你就是其中之一，那么我强烈建议你再次体会 一下前面说的articles分解为subjects/contents的过程，相信你熟悉了以后，下一个应用的速度会有质的提升。

问题：主从服务器读写分离时读操作失败

先重现一下问题：比如说添加一条新数据，添加成功后根据last_insert_id跳转到新添加数据的浏览页面。在此过程中添加新数据的操作是在主服务 器上完成的，浏览新数据的操作实在从服务器上完成的，不过由于主从服务器间SQL同步存在延迟，所以当使用last_insert_id在从服务器上查询 的时候，从服务器很可能还没有还没来得及同步到此记录，所以读操作失败。解决思路也不复杂，在代码里加入一个缓存层（可以使用memcached），新添 加的数据都顺手放到缓存层里一份，新数据的读操作也先查询缓存层，这样就不会再有读操作失败的问题了，当然删除或者更新数据的时候也要顺带着处理好缓存数 据，可以使用观察者模式来搞定。不过这样缓存方案只限于读取单一的记录，对于读取列表的记录的情况，则是无效的。

问题：主从服务器索引是否有必要保持一致

一般都是利用主从服务器完成读写分离，从服务器上进行读操作，主服务器进行写操作，这样的话，主服务器上仅保留主键，外键，唯一索引等必要的索引即可，以 便保持数据合法性，而对于那些原本用于优化SELECT操作的索引，可以全部删除，如此的话主服务器的写操作效率会提升很多。把索引保持在从服务器上还有 一个好处就是实际应用里，我们可能时常要通过ALTER TABLE去调整索引，而ALTER TABLE本身数据剧烈运动，会影响在线业务，为了规避影响，我们可以先停止一台从服务器，然后ALTER TABLE建好索引，然后再把从服务器启动，用这样的方法把所有的从服务器都建好索引，从而平滑的完成了ALTER TABLE操作。

ldw3432

主从服务器表结构都不一样，同步数据会不会有问题啊？