MySQL数据库SQL层级优化

本篇主涉及MySQL SQL Statements层面的优化。

首先，推荐一个连接为万物之始：http://dev.mysql.com/doc/refman/5.0/en/optimization.html

其次，Explain做为分析SQL的优化利器，SHOW STATUS 和 PROCEDURE ANALYSE(16, 256)也蛮有用。推荐两篇MySQL Explain：

http://www.khankennels.com/presentations/pdf/explain.pdf

http://dev.mysql.com/doc/refman/5.0/en/explain-output.html

 

一、一次INSERT多条语句

避免循环单条插入，代价很昂贵！在IBATIS中一次插入多条语句配置：

<insert id="insertUserList" parameterClass="java.util.List">

 <![CDATA[

     insert into user(

         id,

         userName,

         passWord

     ) values

 ]]]]>

 <iterate conjunction=",">

 <![CDATA[

     (

         #list[].id#,

         #list[].userName#,

         #list[].passWord#

     )

 ]]]]>

 </iterate>

 </insert>

 

二、有效利用索引

－Index Unique Column。在MySQL中使用惟一索引会提高效率，仅看成为Search目的、才有必要设置。

－在WHERE条件中尽可能使用索引。

－考虑联合索引，但存在”first hit”问题。

－FORCE INDEX强制使用指定索引列表，SELECT SQL_BUFFER_RESULTS强制使用MySQL生成临时结果集（使得好临时结果集、将大大提高性能，还有SQL_SMALL_RESULT、SQL_BIG_RESULT），USE INDEX给定参考索引列表，IGNORE INDEX给定忽略索引列表。

－避免在索引列使用IS NULL或NOT IS NULL。

三、必定要使用LIMIT 1

大数据集，会占用内存、带宽等资源。使用LIMIT，强迫分页，减小服务器压力。

四、尽量地使用NOT NULL，不管是在WHERE查询仍是表字段设计中使用默认值。

五、Utilize Union instead of OR

Indexes lose their speed advantage when using them in OR-situations in MySQL at least. Hence, this will not be useful although indexes is being applied. 例：

SELECT * FROM EventPrizeUser A WHERE A.`UserID`=39235750 OR A.`UserMobile`='18961751810'

vs.

(SELECT * FROM EventPrizeUser WHERE `UserID`=39235750)

UNION

(SELECT * FROM EventPrizeUser WHERE `UserMobile`='18961751810')

第一条走index_merge，第二条走ref(const)。ref是要优于index_merge，虽然该条语句可能OR的性能略高于UNION（约1ms)，但UNION能够保证必定走索引，而MySQL的OR执行计划不走index_merge的几率也蛮高。OR的每一个条件列都必须使用索引，OR才使用索引。

六、使用合适确数据类型、缩减存储空间

-使用ENUM、而不是VARCHAR。ENUM利用TINYINT、类型紧凑、比较快，但却能够有字符串的“华丽外表”。若是是预约义好的类型，能够尝试SET类型。?ENUM新增类型。使用PROCEDURE ANALYSE分析出表的ENUM建议。

-使用DATE、TIMESTAMP，避免DATETIME。TIMESTAMP的存储空间是DATETIME的一半。

七、避免没必要要排序，如DISTINCT等都会触发排序

－GROUP BY A ORDER BY NULL。GROUP BY默认会使用排序，因此若是结果集比较大、能够采用ORDER BY NULL去掉。

－ORDER BY，仅对WHERE中同个组合索引内的key采用统一ASC/DESC方式

例：SELECT * FROM WHERE part_key1 ORDER BY part_key1 DESC, part_key2 DESC

八、慎用NOT，避免使用IN、 NOT IN、<>、OR或HAVING等

用EXIST、NOT EXISTS代替IN、NOT EXISTS，由于能够直接走关联子句的WHERE。<>能够用 “> & <”代替。如：

SELECT MemberCardID FROM `MC_MemberCard` WHERE MemberCardID <> 1247

vs.

SELECT MemberCardID FROM `MC_MemberCard` WHERE MemberCardID < 1247 OR MemberCardID > 1247

faster 1ms

九、Wildcard，LIKE ‘a%’，NOT ‘%a%’

’a%’为前缀匹配、走索引，但’%a%’致使全表查询。

十、不要以字符形式声明数字

a=一、NOT  a = ‘1’，由于会使索引失效、致使全表扫描。?会么?

十一、禁用SELECT FOR UPDATE

FOR UPDATE属于悲观锁（Pessimistic Locking），在整个数据处理过程当中将处于锁定状态。乐观锁（Optimistic Locking）则采用更加宽松的锁机制。wiki定义以下：

Optimistic concurrency control (OCC) is a concurrency control method for relational database management systems that assumes that multiple transactions can complete without affecting each other, and that therefore transactions can proceed without locking the data resources that they affect. Before committing, each transaction verifies that no other transaction has modified its data. If the check reveals conflicting modifications, the committing transaction rolls back。

乐观锁最经常使用方式是经过version或TIMESTAMP，防止数据不一致问题。修改数据时可利用行写锁保证惟一性：

UPDATE T SET VERSION+1=VERSION WHERE ID=xxx

Hibernate在框架支持乐观锁机制，IBATIS中暂时没有相应支持，但可参考下文：

http://matejtymes.blogspot.hk/2010/11/optimistic-locking-on-ibatis.html

还可以使用前置条件解决并发问题，如：

UPDATE STATUS=’BUY_SUCC’ WHERE OrderId=xxx AND Status=’WAITING_PAY’

十二、垂直分割

水平分割、SQL太复杂很差处理，但经验而言，通常情景下是没有太多效率提高，能够将查询频烦、固定表长的部分做为一部分。？啥时候该作这件事？

1三、高并发写操做的表，不建议使用自增ID

使用自增ID、会引发写锁保护，也不能使用MySQL的UUID()，由于会致使主备数据不一致。并发应用程序中生成ID，保证惟一性、推荐两种方式：

－经典的combined guid/timestamp方式：占32字节，效率太慢。利用BitConverter.ToInt64()转换成8个字节，能够接受的友好；

－根据业务规则自定义方案。如：12位年月日时分秒+3位服务器编码+3位表编码+5位随机码/流水码。?啥级别自增会防碍读写?

1四、使用Prepared Statements（JDBC）

次少SQL解析、生成执行计划次数，顺带过滤注入。在IBATIS中，#{id}表示PreparedStatement parameter，在XML语句配制中有statementType参数，默认为PREPARED。

再送一个SQL优化的网站：

http://www.mysqlperformanceblog.com/