MySQL性能优化之干货篇

3、常用SQL优化

3.1、避免SELECT *

从数据库里读出越多的数据，那么查询就会变得越慢。并且如果你的数据库服务器和WEB服务器是两台独立的服务器的话，这还会增加网络传输的负载。

3.2、避免在where子句中使用!=或<>操作符

应尽量避免在where子句中使用!=或<>操作符，否则引擎放弃使用索引而进行全表扫描。

3.3、尽量避免全表扫描

对查询进行优化，应尽量避免全表扫描，首先应考虑在where及order by涉及的列上建立索引。

3.4、用UNION来代替OR

3.5、like语句避免前置百分号

前置百分号会导致索引失效。

3.6、避免where子句中使用参数

如果在where子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。
如下面语句将进行全表扫描：

select id from t where num=@num

可以改为强制查询使用索引：

select id from t with(index(索引名)) where num=@num

3.7、避免在where子句中对字段进行表达式操作

应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where num/2=100

应改为:

select id from t where num=100*2

3.8、避免在where子句中对字段进行函数操作

应尽量避免在 where 子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where substring(name, 1, 3) = ’abc’ – name 

select id from t where datediff(day, createdate, ’2019-11-30′) = 0 – ’2019-11-30′

生成的 id 应改为:

select id from t where name like ‘abc%’ select id from t where createdate >= ’20019-11-30′ and createdate < ’2019-12-1′

3.9、避免无意义查询

不要写一些没有意义的查询，如需要生成一个空表结构：

select col1,col2 into #t from t where 1=0

这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：

create table #t(…)

3.10、用exists代替in

很多时候用 exists 代替 in 是一个好的选择：

select num from a where num in(select num from b) 

用下面的语句替换：

select num from a where exists(select 1 from b where num=a.num)

3.11、尽量使用数字型字段尽量使用数字型字段

尽量使用数字型字段尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会 逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了

3.12、使用varchar/nvarchar代替char/nchar

尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些

3.13、大临时表使用select into代替create table

在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免造成大量log，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert

3.14、临时表先truncate table，然后drop table

如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定

3.15、存储过程使用SET NOCOUNT ON

在所有的存储过程和触发器的开始处设置SET NOCOUNT ON，在结束时设置SETNOCOUNT OFF。无需在执行存储过程和触发器的每个语句后向客户端发送DONEINPROC 消息

3.16、避免向客户端返回大数据量

尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理

3.17、避免在 where 子句中对字段进行 null 值判断

应尽量避免在where子句中对字段进行null值判断，否则将导致引擎放弃使用索引而进行全表扫描。如：

select id from t where num is null

可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

select id from t where num=0

3.18、GROUP BY关键字优化

1. group by 实质是先排序后分组，遵照索引的最佳左前缀。
2. 当无法使用索引列，增大max_length_for_sort_data参数的设置+增大sort_buffer_size参数的设置
3. where高于having，能写在where限定的条件就不要去having去限定了。

3.19、大数据量的分页优化

使用limit进行分页，翻到10000多页后效率低。原因在于limit offset会逐行查找，是先查询再跳过。从业务逻辑优化优化，不允许翻过100页，例如百度一般可以翻到70页左右。

3.20、优化更须要优化的Query

这个问题须要从对整个系统的影响来考虑。哪个 Query 的优化能给系统整体带来更大的收益，就更须要优化。
一般来说，高并发低消耗的影响 > 低并发高消耗