<p>正常情况下，初创公司的流量并不是很大，mysql数据库在未做优化的情况依然可以满足性能要求，特别是5.6版本后mysql在性能上还是有了很大提升，所以在初期并没有花精力在此上面。但后来发生的一系列问题还是说明mysql性能优化在项目启动时就应该重视起来。下面就出现问题的原因和需要注意的地方说明如下：</p>    <h2><strong>问题来源</strong></h2>    <p>开发人员之前多数使用oracle，由于oracle强大的性能和所做项目多是内部企业应用，不太可能出现性能问题。在这样的背景下，开发人员依然按照原来的方式来写代码，导致后来性能问题，总结有以下几点：</p>    <p>1.sql多表联合查询，常常是3，4张表联合查询</p>    <p>2.sql中使用大量函数</p>    <p>3.sql中直接select *</p>    <p>4.表字段缺少索引或者索引方式不对</p>    <p>5.表设计考虑不周，出现大量空字段</p>    <p>6.表主键设计成UUID，由于使用传统机械硬盘，对寻址非常不利</p>    <p>7.过多使用触发器</p>    <p>8.sql中存在复杂计算</p>    <h2><strong>解决方案</strong></h2>    <p>首先通过慢日志过滤出大于1s的sql语句，解决mysql性能问题，一定要利用好慢日志。然后通过执行计划（explain）来查看sql的执行情况。具体优化措施如下：</p>    <h3><strong>联合查询分拆成单表查询</strong></h3>    <p>如果此sql是联合查询，首先确认是否是可以拆分成单表查询，然后通过程序来进行处理数据。最多不能超过两表联合查询。</p>    <h3><strong>建立合适索引</strong></h3>    <p>通过执行计划，对全表扫描的查询一定要建立索引，在建立索引时，一定要考虑到此字段是否有大量空字段，字段值是否大量重复，可区分度是否高，不然建立索引的意义不大，反而是影响insert 和 delete操作。对于长字符类型的字段，增加算因时，需要增加前缀，计算方式为：select count(distinct left(b,5)) /count(distinct b) as left5,count(distinct left(b,6))/count(distinct b) as left6 from test_unique limit 1，其中5，6是预估值，对于UUID这样长字符类型，一般前缀是6.增加索引时sql语句为：alter table test.test_unique add key (left(6));。 对于不能重复的字段，建议使用唯一索引，一是保证插入值唯一，二是提高查询速度 。 在where、order 、group by后面的字段，尽量建立索引，通过需要注意的是如果where后面是多字段，那么需要建立联合索引，而不是单个建立索引，并且需要注意联合索引的顺序，例如where a='x' and b = 'y'，在其它sql中出现where b=‘z’这样的情况，那么联合索引顺序为（b,a），而不是单独建立（a,b）和（b）两个索引，因为在建立联合索引（b,a）时，mysql会建立两个索引(b)，（b,a）两个索引。</p>    <h3><strong>避免索引失效</strong></h3>    <p>在字段上使用函数将会使索引失效，因此一定要避免在左侧字段使用函数，而是提前在程序里处理好。</p>    <h3><strong>尽量避免函数</strong></h3>    <p>mysql提供了大量的函数，但对于这些函数，尽量不要用，而是在程序里进行处理，目前mysql对于这些函数优化工作做的并不是很好，往往有时候会导致严重的性能问题。</p>    <h3><strong>表主键使用自增序列</strong></h3>    <p>表主键尽量采用自增序列，这样可以充分mysql的存储特性，mysql采用B+树存储。需要注意的地方在于：如果是分库分表，那么需要不能直接使用自增序列，需要采用其他方法来完成，常用的方式通过redis来维护一套ID。</p>    <p>via： http://www.jizhuomi.com/software/568.html</p>