mysql 优化技巧

count(*) 优化：

有时候某些业务场景并不需要完全精确的COUNT值，可以用近似值来代替，EXPLAIN出来的行数就是一个不错的近似值，而且执行EXPLAIN并不需要真正地去执行查询，所以成本非常低。实例：[SQL]select count(name) from aaa;受影响的行: 0时间: 2.957s结果：428396[SQL]EXPLAIN select count(name) from aaa;受影响的行: 0时间: 0.038s结果：1   SIMPLE  aaa index       name_idx    767     413996  Using index

通常来说，执行COUNT()都需要扫描大量的行才能获取到精确的数据，因此很难优化，MySQL层面还能做得也就只有覆盖索引了。如果不还能解决问题，只有从架构层面解决了，比如添加汇总表，或者使用redis这样的外部缓存系统。

关联查询优化：

　　在大数据场景下，表与表之间通过一个冗余字段来关联，要比直接使用JOIN有更好的性能。如果确实需要使用关联查询的情况下，需要特别注意的是：　　1、确保ON和USING字句中的列上有索引。在创建索引的时候就要考虑到关联的顺序。当表A和表B用列c关联的时候，如果优化器关联的顺序是A、B，那么就不需要在A表的对应列上创建索引。2、没有用到的索引会带来额外的负担，一般来说，除非有其他理由，只需要在关联顺序中的第二张表的相应列上创建索引。3、确保任何的GROUP BY和ORDER BY中的表达式只涉及到一个表中的列，这样MySQL才有可能使用索引来优化。

union 优化：

　　MySQL处理UNION的策略是先创建临时表，然后再把各个查询结果插入到临时表中，最后再来做查询。因此很多优化策略在UNION查询中都没有办法很好的时候。经常需要手动将WHERE、LIMIT、ORDER BY等字句“下推”到各个子查询中，以便优化器可以充分利用这些条件先优化。　　　　除非确实需要服务器去重，否则就一定要使用UNION ALL，如果没有ALL关键字，MySQL会给临时表加上DISTINCT选项，这会导致整个临时表的数据做唯一性检查，这样做的代价非常高。当然即使使用ALL关键字，MySQL总是将结果放入临时表，然后再读出，再返回给客户端。虽然很多时候没有这个必要，比如有时候可以直接把每个子查询的结果返回给客户端。

大表 alter table：

大表ALTER TABLE非常耗时，MySQL执行大部分修改表结果操作的方法是用新的结构创建一个张空表，从旧表中查出所有的数据插入新表，然后再删除旧表。尤其当内存不足而表又很大，而且还有很大索引的情况下，耗时更久。当然有一些奇淫技巧可以解决这个问题，有兴趣可自行查阅。比如：大表更改默认值使用alter table不重建表，直接修改.frm    在MySQL中执行很大部分的修改动作，都需要重建一个表，然后把数据放进去，最后删除旧的表！有时候要是有索引的列上进行大批且频繁的表的时候会导致系统的性能严重下降，这里可以在修改SQL上做部分调整，减轻相关的构建结构带来的系统压力问题！    例如 在修改一个表的默认值为8的时候，常规做法为：（1）：alter table  modes modify column  dept tinyint(3) not null default 8；这里通过一些show status分析出，每次都要做大量的句柄的读取和插入操作，类似于从新构建了一张新表的样式，这样在一些大表，上千万的数据量会出现瓶颈问题！这里我们需要灵活知道mysql的相关默认值实际是放在相关的表结构.frm文件中；我们可以不经过数据层，可以直接调整！上述的modify column会导致相关的表进行拷贝操作，不利于系统的正常稳定运行，可以使用下面方式；（2）：alter table modes alter column dept set default 8;这里只是更改了相关的frm文件，没有改动表，因此速度很快的即可完成；总结：在此我们可以注意到相关的alter table后面跟不同形式的命令，可以对数据产生了不同程度的影响，这里还有一个change column操作也是不一样的！