mysql优化顺序

mysql优化顺序：

1. 优化你的sql和索引
2. 添加缓存，memcached,redis
3. 主从复制或主主复制，读写分离，可以在应用层做，效率高，也可以使用第三方工具，如atlas
4. 使用mysql的自带分区表，自己的应用是透明的，无需更改代码，但是sql语句是需要针对分区表做优化的，sql条件中要带上分区条件的列，从而使查询定位到少量地分区上，否则就会扫描全部分区。
5. 做垂直拆分，其实就是根据你模块的耦合度，讲一个大的系统分为多个小的系统，也就是分布式系统。
6. 水平切分，针对数据量大的表，这一步最麻烦，最能考验技术水平，要选择一个合适的sharding
   key,为了有好的查询效率，表结构也要改动，做一定的冗余，应用也要改，sql中尽量带sharding
   key,将数据定位到限定的表上去差，而不是扫描全部的表；
7. 有人也许要说第一步优化sql和索引这还用说吗？的确，大家都知道，但是很多情况下，这一步做的并不到位，甚至有的只做了根据sql去建索引，根本没对sql优化（中枪了没？），除了最简单的增删改查外，想实现一个查询，可以写出很多种查询语句，不同的语句，根据你选择的引擎、表中数据的分布情况、索引情况、数据库优化策略、查询中的锁策略等因素，最终查询的效率相差很大；优化要从整体去考虑，有时你优化一条语句后，其它查询反而效率被降低了，所以要取一个平衡点；即使精通mysql的话，除了纯技术面优化，还要根据业务面去优化sql语句，这样才能达到最优效果；你敢说你的sql和索引已经是最优了吗?
8. 不同引擎的优化，myisam读的效果好，写的效率差，这和它数据存储格式，索引上的指针和锁的策略是有关的，它的数据是顺序存储的(innode数据存储方式是聚簇索引)，它的索引btree上的节点是一个指向数据物理位置的指针，索引查找起来很快，(innodb索引节点存的则是数据的主键，所以需要根据主键进行二次查找)；myisam锁是表锁，只有读读之间是并发的，写写之间和读写之间（读和插入之间是可以并发的，去设置concurrent_insert参数，定期执行表优化操作，更新操作就没有办法了）是串行的。所以写起来很慢，并且默认的写优先级比读优先级高，高到写操作来了后，可以马上插入到读操作前面去，如果批量写，会导致读请求饿死，所以要设置读写优先级或设置多少写操作后执行读操作的策略；myisam不要使用查询时间太长的sql,如果策略使用不当，也会导致写饿死，所以尽量去拆分查询效率较低的sql.
9. innodb一般都是行锁，这个一般值得是sql用到索引的时候，行锁是加在索引上的，不是加在数据记录上的，如果sql没有用到索引，仍然会锁定表，mysql的读写之间是可以并发的，普通的select是不需要锁的，当查询的记录遇到锁时，用的是一致性的非锁定快照读，也就是根据数据库隔离级别策略，会去读被锁定行的快照，其他更新或锁定读语句用的是当前读，读取原始行；因为普通读与写不冲突，所以innodb不会出现读写饿死的情况，有因为在使用索引的时候用的是行锁，锁的粒度小，竞争相同锁的情况就少，就增加了并发处理，所以并发读写的效率还是很优秀的，问题在于索引查询后的根据主键的二次查找导致效率低；