admin 管理员组文章数量: 1086019
2024年4月17日发(作者：maven添加mysqljdbc的jar包)
索引问题
在做性能跟踪分析过程中，经常发现有不少后台程序的性能问题是因为缺少合适索引造成
的，有些表甚至一个索引都没有。这种情况往往都是因为在设计表时，没去定义索引，而开
发初期，由于表记录很少，索引创建与否，可能对性能没啥影响，开发人员因此也未多加重
视。然一旦程序发布到生产环境，随着时间的推移，表记录越来越多，这时缺少索引，对性
能的影响便会越来越大了。
这个问题需要数据库设计人员和开发人员共同关注
法则：不要在建立的索引的数据列上进行下列操作:
避免对索引字段进行计算操作
避免在索引字段上使用not，<>，!=
避免在索引列上使用IS NULL和IS NOT NULL
避免在索引列上出现数据类型转换
避免在索引字段上使用函数
避免建立索引的列中使用空值。
避免对索引字段进行计算操作"
如果你对索引行进行了类似ROUND的计算操作，SQL就会进行扫描（一般会进行表扫描；在
聚集索引情况下会进行聚集索引扫描，性能表现基本和表扫描没啥大区别；如果是非聚集索
引，则要进行索引扫描。），这一条和“避免在索引字段上使用函数”原理相同。因为一旦
进行了函数运算，该WHERE子句就不是 SARG（可搜索参数化表达式）SQL没办法优化。当
然，对索引进行WHERE A+3=5这样的代数运算SQL优化时会自动转为WHERE A=5-3
但是如果可以，我建议你直接写成 WHERE A=5-3这样的形式，因为SQL在实际执行的时候
有还存在一个数据比对的精确度问题。
“避免在索引字段上使用not，<>，!=”
“避免在索引列上使用IS NULL和IS NOT NULL”
这几条条说白了，一旦使用了这样的运算符，WHERE子句就不是一个SARG（可搜索的参数
化表达式），这样的字句是不能运用索引的。
低效: (索引失效)
SELECT „ FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL;
高效: (索引有效)
SELECT „ FROM DEPARTMENT WHERE DEPT_CODE >=0;
“避免在索引列上出现数据类型转换”，
如果明确运用函数进行类型转换，上面已经说原因了。但如果出现类似 WHERE ORDER_ID='3'
这样的子句，(ORDER_ID为INT型)，SQL会隐式转换，也可能无法运用索引（理论山我认为
是这样，需要实际测试验证）。
“避免建立索引的列中使用空值”，
一旦在索引列有NULL，可能会对索引密度造成影响（要看表的实际的数据填充情况），从
而损害选择性。
在可以使用UNION ALL的语句里，不使用了UNION
UNION 因为会将各查询子集的记录做比较，故比起UNION ALL ，通常速度都会慢上许多。
对Where 语句的法则
1 避免在WHERE子句中使用in，not in，or 或者having。
可以使用 exists 和not exists代替 in和not in。
可以使用表链接代替 exists。
Having可以用where代替，如果无法代替可以分两步处理。
例子
SELECT pub_name FROM publishers
WHERE pub_id IN(SELECT pub_id FROM titles)
优化
SELECT pub_name FROM publishers
WHERE EXISTS(SELECT * FROM titles WHERE pub_id = _id)
GO
2 不要以字符格式声明数字，要以数字格式声明字符值。（日期同样）
否则会使索引无效，产生全表扫描。
例子
使用：SELECT , FROM emp WHERE = 7369;
不要使用：SELECT , FROM emp WHERE = ‘7369’
使用表的别名(Alias)：
当在SQL语句中连接多个表时, 请使用表的别名并把别名前缀于每个Column上.这样一来,
就可以减少解析的时间并减少那些由Column歧义引起的语法错误.
版权声明：本文标题：SQL性能优化. 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.roclinux.cn/b/1713351040a630368.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论