开心一笑
【小男孩问妈妈：“妈妈，我到底是从哪里来的？”妈妈就支吾地解释了半天生殖的过程。儿子听完一头雾水地说：怎么会这样？我的同桌说他是从山西来的！】
提出问题
如何提升数据库性能???
唯美图片
解决问题
最近接触到数据库PostgreSQL的性能优化，看了很多网上的SQL优化文章，整理分享下：
SQL语句大小写规范
我们在写SQL的时候，通常会出现大小写混用的情况。如下：
select * FROM pm_testcase pt where pt.Name = 'ay'
正确的做法是SQL语句全部大写或者全部小写。如下：
-- 全部小写
select * from pm_testcase pt where pt.name = 'ay'
-- 全部大写
SELECT * FROM PM_TESTCASE PT WHERE PT.NAME = 'ay'
PostgreSQL执行计划
PostgreSQL的执行计划，做为数据库性能调优的利器，有必要在开头简单的介绍下。
explain analyse select * from pm_testcase pt
--执行计划
Seq Scan on pm_testcase pt (cost=0.00..5237.11 rows=60011 width=2020) (actual time=37.347..435.601 rows=60012 loops=1)
Planning time: 0.426 ms
Execution time: 438.442 ms
cost说明：
- 第一个数字0.00表示启动cost，这是执行到返回第一行时需要的cost值。
- 第二个数字4621.00表示执行整个SQL的cost
通过查看执行计划，我们就能够找到SQL中的哪部分比较慢，或者说花费时间多。然后重点分析哪部分的逻辑，比如减少循环查询，或者强制改变执行计划。
更多执行计划 Explain，可网上搜索。
建立索引避免全表扫描
首先，在数据库里有一张表 pm_testcase，里面有150万条数据。
如下SQL，我们利用执行计划，对创建时间（created_time）进行排序，输出执行计划结果。
程序清单 2-1
explain
select * from pm_testcase pt
order by pt.created_time desc
--Sort (cost=4103259.72..4107084.44 rows=1529885 width=1920)
--Sort Key: created_time
---> Seq Scan on pm_testcase pt (cost=0.00..134087.85 rows=1529885 width=1920)
cost=说明：
第一个数字4103259.72表示启动cost，这是执行到返回第一行时需要的cost值。
第二个数字4107084.44表示执行整个SQL的cost。
该语句总共耗时 4107084.44
这里我们创建 created_time 索引，对相同语句执行 程序清单 2-1 的SQL，得到的执行计划结果为：
Index Scan Backward using idx_create_time on pm_testcase pt (cost=0.43..384739.28 rows=1530024 width=1920)
很明显，执行整个SQL的 cost 由 4107084.44 减少到 384739.28
因此，为了避免全表扫描，建议在考虑在 where 及 order by 涉及的列上建立索引。
防止索引失效
我们应尽量避免在 where 子句中使用 != 或 <> 操作符，否则引擎将放弃使用索引而进行全表扫描。
如下例子，我们在 pm_testcase 的 code 上添加了索引：
explain select pt.code from pm_testcase pt
where pt.code != 'case005510'
--执行计划，Seq Scan 全表扫描
Seq Scan on pm_testcase pt (cost=0.00..137914.30 rows=1529973 width=11)
explain select pt.code from pm_testcase pt
where pt.code = 'case005510'
--执行计划，Bitmap Heap Scan 索引扫描
Bitmap Heap Scan on pm_testcase pt (cost=4.82..206.29 rows=51 width=11)
通过上面的例子可以看出，!= 操作符使得索引失效。
避免建立太多的索引
索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 和 update 的效率，因为 insert 或 update 时有可能会重建索引，所以视具体情况而定。一个表的索引数最好不要超过7个，若太多则应考虑一些不常使用到的列上建的索引是否有必要.
关于查询效率的几点建议
- 尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。
- 尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为变长字段存储空间小，对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
- 最好不要给数据库留NULL，尽可能的使用 NOT NULL填充数据库。备注、描述、评论之类的可以设置为 NULL。其他的，最好不要使用NULL。
- 任何地方都不要使用 select * from t ，用具体的字段列表代替 * ，不要返回用不到的任何字段。
- 应尽量避免在 where 子句中使用 or 来连接条件,可以考虑使用 union 代替
- in 和 not in 也要慎用。对于连续的数值，能用 between 就不要用 in，exists 代替 in
- 尽量避免在 where 子句中对字段进行表达式操作和函数操作
在Join表的时候字段使用相同类型，并将其索引
如果你的应用程序有很多JOIN查询，你应该确认两个表中Join的字段是被建过索引的。这样，SQL内部会启动为你优化Join的SQL语句的机制。而且，这些被用来Join的字段，应该是相同的类型的。例如：如果你要把 DECIMAL 字段和一个 INT 字段 Join 在一起，SQL 就无法使用它们的索引。对于那些STRING 类型，还需要有相同的字符集才行。（两个表的字符集有可能不一样）程序员站
优化子查询
子查询很灵活可以极大的节省查询的步骤，但是子查询的执行效率不高。执行子查询时数据库需要为内部嵌套的语句查询的结果建立一个临时表，然后再使用临时表中的数据进行查询。查询完成后再删除这个临时表，所以子查询的速度会慢一点。
我们可以使用join语句来替换掉子查询，来提高效率。join语句不需要建立临时表，所以其查询速度会优于子查询。大部分的不是很复杂的子查询都可以替换成join语句。
读书感悟
来自《儿子与情人》
- 爱情应该给人一种自由感，而不是囚禁感。
- 家就是家，不论有过多大痛苦，他们都相互爱恋。
- 一个人往往受生活的支配，生活支撑人的躯壳，完成人的历史使命，但同时却又虚无缥缈，仿佛任人去，自生自灭，不闻不问。
经典故事
【某大公司准备以高薪雇用一名小车司机，经过层层筛选和考试之后，只剩下三名技术最优良的竞争者。主考者问他们：“悬崖边有块金子，你们开着车去拿，觉得能距离悬崖多近而又不至于掉落呢？”
“二公尺。”第一位说。
“半公尺。”第二位很有把握地说。
“我会尽量远离悬崖，愈远愈好。”第三位说。
结果这家公司录取了第三位。
秘诀：不要和诱惑较劲，而应离得越远越好。】
大神文章
【1】MySQL性能优化的最佳21条经验
【2】 Java面试准备十六：数据库——MySQL性能优化
【3】 提高mysql千万级大数据SQL查询优化30条经验
【4】PostgreSQL执行计划的解释
【5】 PostgreSQL SQL的性能调试方法3--查看执行计划
【6】postgreSql性能优化提升技巧指南
【7】修改一行代码提升 Postgres 性能 100 倍
【8】PostgreSQL 性能调优
其他
如果有带给你一丝丝小快乐，就让快乐继续传递下去，欢迎点赞、顶、欢迎留下宝贵的意见、多谢支持！
网友评论