MySQL数据库SQL层级优化_MySQL

本篇主涉及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

1、一次INSERT多条语句

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

insert into user(

id,

userName,

passWord

) values

]]]]>

(

#list[].id#,

#list[].userName#,

#list[].passWord#

)

]]]]>

2、有效利用索引

－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。

3、一定要使用LIMIT 1

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

4、尽可能地使用NOT NULL，无论是在WHERE查询还是表字段设计中使用默认值。

5、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才使用索引。

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

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

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

7、避免不必要排序，如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

8、慎用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

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

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

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

a=1、NOT a = ‘1’，因为会使索引失效、导致全表扫描。?会么?

11、禁用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’

12、垂直分割

水平分割、SQL太复杂不好处理，但经验而言，一般情景下是没有太多效率提升，可以将查询频烦、固定表长的部分作为一部分。？啥时候该做这件事？

13、高并发写操作的表，不建议使用自增ID

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

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

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

14、使用Prepared Statements（JDBC）

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

再送一个SQL优化的网站：

http://www.mysqlperformanceblog.com/