基于mysql的sql优化方法_介绍几种提升mysql的性能和对于sql的优化的方法

笔者本身平时由于用mysql比较多，并且mysql的数据量也比较大，因此这里但愿可以提供一些优化mysql数据库的一些方法，每招都是成本从低到高。也是通常咱们开发先执行的顺序。mysql

第一招：redis

优化你的sql和添加索引，还有设置存储引擎 (MYISAM和INNODB)；sql

(好比你查询的sql尽可能查到恰好够用的数据就好，索引不要太多要设置的合理，对于常常要查询的字段记得添加索引。若是一个表对事物要求不高，咱们能够选MYISAM提升本身表的性能，这些都要根据实际业务本身作调整)数据库

第二招：缓存

加缓存，memcached,redis；并发

(对于不少数据，咱们均可以用memcached和redis进行缓存，如今比较推荐redis，使用no sql数据库缓存的话可以大幅度提升数据库的性能)

分布式

第三招：memcached

能够对数据库作主从复制或主主复制，读写分离，能够在应用层作，效率高，也能够用三方工具，第三方工具推荐360的atlas。工具

(不懂的你们能够去百度主从库。通常就是有一个主库和一个从库，从库会实时复制主库的信息，而后主库负责写和改数据，而后从库负责读数据)

性能

第四招：

若是你仍是以为不够快，先不要想着去作切分，mysql自带分区表，先试试这个，对你的应用是透明的，无需更改代码,可是sql语句是须要针对分区表作优化的，sql条件中要带上分区条件的列，从而使查询定位到少许的分区上，不然就会扫描所有分区，另外分区表还有一些坑，在这里就很少说了；

第五招：

若是以为还不够快，那就先作垂直拆分，其实就是根据你模块的耦合度，将一个大的系统分为多个小的系统，也就是分布式系统；

第六招：

接下来才是水平切分，针对数据量大的表，这一步最麻烦，最能考验技术水平，要选择一个合理的sharding key,为了有好的查询效率，表结构也要改动，作必定的冗余，应用也要改，sql中尽可能带sharding key，将数据定位到限定的表上去查，而不是扫描所有的表；

mysql数据库通常都是按照这个步骤去演化的，成本也是由低到高；

有人也许要说第一步优化sql和索引这还用说吗？的确，你们都知道，可是不少状况下，这一步作的并不到位，甚至有的只作了根据sql去建索引，根本没对sql优化(中枪了没？)，除了最简单的增删改查外，想实现一个查询，能够写出不少种查询语句，不一样的语句，根据你选择的引擎、表中数据的分布状况、索引状况、数据库优化策略、查询中的锁策略等因素，最终查询的效率相差很大；优化要从总体去考虑，有时你优化一条语句后，其它查询反而效率被下降了，因此要取一个平衡点；即便精通mysql的话，除了纯技术面优化，还要根据业务面去优化sql语句，这样才能达到最优效果；你敢说你的sql和索引已是最优了吗?

再说一下不一样引擎的优化，myisam读的效果好，写的效率差，这和它数据存储格式，索引的指针和锁的策略有关的，它的数据是顺序存储的(innodb数据存储方式是聚簇索引)，他的索引btree上的节点是一个指向数据物理位置的指针，因此查找起来很快，(innodb索引节点存的则是数据的主键，因此须要根据主键二次查找)；myisam锁是表锁，只有读读之间是并发的，写写之间和读写之间(读和插入之间是能够并发的，去设置concurrent_insert参数，按期执行表优化操做，更新操做就没有办法了)是串行的，因此写起来慢，而且默认的写优先级比读优先级高，高到写操做来了后，能够立刻插入到读操做前面去，若是批量写，会致使读请求饿死，因此要设置读写优先级或设置多少写操做后执行读操做的策略;myisam不要使用查询时间太长的sql，若是策略使用不当，也会致使写饿死，因此尽可能去拆分查询效率低的sql,

innodb通常都是行锁，这个通常指的是sql用到索引的时候，行锁是加在索引上的，不是加在数据记录上的，若是sql没有用到索引，仍然会锁定表,mysql的读写之间是能够并发的，普通的select是不须要锁的，当查询的记录遇到锁时，用的是一致性的非锁定快照读，也就是根据数据库隔离级别策略，会去读被锁定行的快照，其它更新或加锁读语句用的是当前读，读取原始行；由于普通读与写不冲突，因此innodb不会出现读写饿死的状况，又由于在使用索引的时候用的是行锁，锁的粒度小，竞争相同锁的状况就少，就增长了并发处理，因此并发读写的效率仍是很优秀的，问题在于索引查询后的根据主键的二次查找致使效率低；

ps:很奇怪，为什innodb的索引叶子节点存的是主键而不是像mysism同样存数据的物理地址指针吗？若是存的是物理地址指针不就不须要二次查找了吗，这也是我开始的疑惑，根据mysism和innodb数据存储方式的差别去想，你就会明白了，我就不费口舌了！

因此innodb为了不二次查找可使用索引覆盖技术，没法使用索引覆盖的，再延伸一下就是基于索引覆盖实现延迟关联；不知道什么是索引覆盖的，建议你不管如何都要弄清楚它是怎么回事！尽你所能去优化你的sql吧！说它成本低，却又是一项费时费力的活，须要在技术与业务都熟悉的状况下，用心去优化才能作到最优，优化后的效果也是立竿见影的！