SQL常见的可优化点
# 索引相关
# ###################################################
1. 查询(或更新,删除,可以转换为查询)没有用到索引
这是最基础的步骤,需要对sql执行explain查看执行计划中是否用到了索引,需要重点关注type=ALL, key=NULL的字段。
2. 在索引字段上施加函数
to_char(gmt_created, ‘mmdd’) = ’0101′
正确的写法
gmt_created between to_date(“20090101″, “yyyymmdd”) and to_date(“20090102″, “yyyymmdd”)
3. 在索引字段上使用全模糊
member_id like ‘%alibab%’
B树无法解决此类问题,可以考虑搜索引擎。
但是member_id like ‘alibab%’可以用到索引。
其实,对任何一个字段使用 like ‘%xxxx%’都是一种不规范的做法,需要能检查到这种错误用法。
4. 多列字段的索引,没有用到前导索引
索引:(memeber_id, group_id)
where group_id=9234,实际上,这个条件是没有办法用到上面的索引的。这是一个很常见的误用。要理解为什么不能用到这个索引,需要理解mysql如何构造多列索引的。
索引是一棵B树,问题是,对于多列索引,mysql将索引字段按照索引建立的顺序进行拼装,组成一个新的字符串,这个字符串被用来做为构建B树的键。所以,在查询条件里,如果没有用到前导列,就没办法访问多列索引的B树。
应该建立索引:(group_id, member_id)
5. 访问到了索引之外的字段
索引(member_id, subject)
select subject from offer where member_id=234
在member_id=234记录数很多的情况下,会优于
select subject, gmt_created from offer where member_id=234
原因是第二条sql会根据索引查找到的rowid访问表里的记录。第一条sql使用索引范围扫描就可以得到结果。
如果某个sql执行次数很多,但是读取的字段没有被索引覆盖,那么,可能需要建立覆盖性索引。
6. 计数count(id)有时比count(*)慢
count(id) === count(1) where id is not null
如果没有(id)索引,那么会用全表扫描,而count(*)会使用最优的索引进行用索引快速全扫描
计数统一使用count(*)
7. 正确使用stop机制
判断member_id在offer表中是否存在记录:
select count(*) from offer where member_id=234 limit 1
优于
select count(*) from offer where member_id=234
原因是第一条sql会在得到第一条符合条件的记录后停止。
# ###################################################
# 高效分页
# ###################################################
1. 高效的分页
使用join技术,利用索引查找到符合条件的id,构造成临时表,用这个小的临时表与原表做join
select *
from
(
select t.*, rownum AS rn
from
(select * from blog.blog_article
where domain_id=1
and draft=0
order by domain_id, draft, gmt_created desc) t
where rownum >= 2
) a
where a.rn <= 3
应该改写成
select blog_article.*
from
(
select rid, rownum as rn
from
(
select rowid as id from blog.blog_article
where domain_id=1
and draft=0
order by domain_id, draft, gmt_created desc
) t
where rownum >= 2
) a, blog_article
where a.rn >= 3
and a.rid = blog_article.rowid
2. order by没有用到索引
有索引(a, b,c )
混合排序规则
ORDER BY a ASC, b DESC, c DESC /* mixed sort direction */
缺失了前导列
WHERE g = const ORDER BY b, c /* a prefix is missing */
缺失了中间列
WHERE a = const ORDER BY c /* b is missing */
使用了不在索引中的列进行排序
WHERE a = const ORDER BY a, d /* d is not part of index */
# ###################################################
# 高效地利用primary key
# ###################################################
随机查询
一个错误的做法:
select * from title where kind_id=1 order by rand() limit 1;
create index k on title(kind_id);
这个sql执行过程中需要全表扫描,并且将数据保存到临时表,这是一个非常耗时的操作。
改进的做法,利用偏移量。
select round(rand() * count(*)) from title where kind_id=1;
select * from title where kind_id=1 limit 1 offset $random;
create index k on title(kind_id);
相比上面的做法,这种写法能够利用到kind_id上的索引,减少了需要扫描的数据块。但是,如果offset非常大,那么需要扫描的数据块也非常大,极端情况是扫描索引k的所有数据块。
最优的做法,利用主键进行范围查找
select round(rand() * count(*)) from title where kind_id=1;
select * from title where kind_id = and id > $random limit 1;
这个sql利用primary key进行范围查询,完全走索引,并且只读取一条记录,速度非常快。但是,这种用法的限制是primary key必须是int型,并且是连续自增长的。
# ###################################################
# 高效join
# ###################################################
子查询是一个影响性能的隐患。应该使用join改写sql。
# ###################################################
# 数据类型
# ###################################################
1. 避免隐式转换
CREATE TABLE `user` (
`id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
`account` char(11) NOT NULL COMMENT ”,
`email` varchar(128),
PRIMARY KEY (`id`),
UNIQUE KEY `username` (`account`)
) ENGINE=InnoDB CHARSET=utf8;
mysql> explain select * from user where account=123 \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: user
type: ALL
possible_keys: username
key: NULL
key_len: NULL
ref: NULL
rows: 2
Extra: Using where
1 row in set (0.00 sec)
可以看到,account=123的条件并没有用到唯一索引`username`。mysql的server从storage engine中读取所有的记录,使用to_number()函数,将记录中的account转换成数字,被转换后的数字用来和参数比较。我们的测试表里有2条记录,而执行计划中rows的值也是2,并且type的值为ALL,这也说明索引`username`并没有被用到。
mysql> explain select * from user where account=’123′ \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: user
type: const
possible_keys: username
key: username
key_len: 33
ref: const
rows: 1
Extra:
1 row in set (0.00 sec)
参数为字符串类型,我们可以看到索引`username`,被使用到了。
这是一个经常被误用的做法。
2. 主键不是自增列
自增列的主键有多个好处:
插入性能高。
减小page的碎片。
提供二级索引的性能,降低二级索引的空间,因为二级索引存储的是主键的值,并不是page中的行id。
SQL常见的可优化点的更多相关文章
- MYSQL常见的可优化点
MYSQL常见的可优化点 SQL常见的可优化点 2014年6月8日 DBA 发表回复 # #################################################### 索引 ...
- PL/SQL常见设置--Kevin的专栏
body { font-family: "Microsoft YaHei UI","Microsoft YaHei",SimSun,"Segoe UI ...
- 深入MySQL(四):MySQL的SQL查询语句性能优化概述
关于SQL查询语句的优化,有一些一般的优化步骤,本节就介绍一下通用的优化步骤. 一条查询语句是如何执行的 首先,我们如果要明白一条查询语句所运行的过程,这样我们才能针对过程去进行优化. 参考我之前画的 ...
- 使用阿里云RDS for SQL Server性能洞察优化数据库负载-初识性能洞察
简介 数据库性能调优通常需要较高数据库水平,并伴随较多的前期准备工作,比如收集各种性能基线.不同种类的性能指标.慢SQL日志等,这通常费时费力且效果一般,当面对多个数据库时总体拥有成本会大幅增加.今天 ...
- 【转】使用SQL Tuning Advisor STA优化SQL
SQL优化器(SQL Tuning Advisor STA)是Oracle10g中推出的帮助DBA优化工具,它的特点是简单.智能,DBA值需要调用函数就可以给出一个性能很差的语句的优化结果.下面介绍一 ...
- 【转】MySQL批量SQL插入各种性能优化
原文:http://mp.weixin.qq.com/s?__biz=MzA5MzY4NTQwMA==&mid=403182899&idx=1&sn=74edf28b0bd29 ...
- SQL Server数据库性能优化之SQL语句篇【转】
SQL Server数据库性能优化之SQL语句篇http://www.blogjava.net/allen-zhe/archive/2010/07/23/326927.html 近期项目需要, 做了一 ...
- SQL SERVER 查询性能优化——分析事务与锁(五)
SQL SERVER 查询性能优化——分析事务与锁(一) SQL SERVER 查询性能优化——分析事务与锁(二) SQL SERVER 查询性能优化——分析事务与锁(三) 上接SQL SERVER ...
- SQL Server 查询性能优化 相关文章
来自: SQL Server 查询性能优化——堆表.碎片与索引(一) SQL Server 查询性能优化——堆表.碎片与索引(二) SQL Server 查询性能优化——覆盖索引(一) SQL Ser ...
随机推荐
- Java 集合源码解析(1):Iterator
Java, Android 开发也有段时间了,当初为了早点学 Android,Java 匆匆了解个大概就结束了,基础不够扎实. 虽然集合框架经常用,但是一直没有仔细看看原理,仅止于会用,不知道为什么要 ...
- 自定义Session类实现
public class CustomizeSession { private HttpSessionState _sesssion = HttpContext.Current.Session; pu ...
- [DP]数位DP总结
数位DP总结 By Wine93 2013.7 1.学习链接 [数位DP] Step by Step http://blog.csdn.net/dslovemz/article/details/ ...
- C/C++学习之路----volatile
因为经常看见volatile这个关键词,想想自己对这个volatile也不是很清楚,仅仅知道它表明变量是易于变化的和防止编译器优化.所以就在网上找了一些其他道友对于volatile的理解,仔仔细细看了 ...
- 第一个Sprint冲刺第五天
讨论成员:邵家文.李新.朱浩龙.陈俊金 讨论问题:掌握计时技术的知识 讨论地点:qq网络 进展:完成对功能的理解
- FreeBSD基金会添加新成员,梁莉成为第一位来自微软和中国的基金会董事
这个月23日FreeBSD基金会很高兴地宣布Philip Paeps和Kylie Liang (梁莉)正式加入董事会. 梁莉,现任微软开源技术部高级项目经理,主要负责FreeBSD在公有云以及私有云的 ...
- 关于kinect的安装与配置工作
一 关于kinect的安装与配置工作 首先要注意的是,使用kinect进行开发,目前有两种不同的驱动方案,经测试这两种方案的驱动是不能兼容的,所以请务必选定其中一种(最好是卸载另外一种). 方案一:使 ...
- ANTLR3完全参考指南读书笔记[05]
前言 仅生成给出true/false的识别器是没有多大用处的,自然的就有在识别过程中遇到某一结构时执行一段代码.存储该结构中信息的想法. ANTLR提供了在文法中嵌入属性和动作超级混合“文法”,可以生 ...
- 235. Lowest Common Ancestor of a Binary Search Tree
代码如下: /** * Definition for a binary tree node. * public class TreeNode { * int val; * TreeNode left; ...
- Codeforces Round #374 (Div. 2) A B C D 水 模拟 dp+dfs 优先队列
A. One-dimensional Japanese Crossword time limit per test 1 second memory limit per test 256 megabyt ...