我提供给你10多条仅优化SQL的简单内容：
1.mysql一次查询只能使用一个索引。如果要对多个字段使用索引，建立复合索引。
2.在ORDER BY操作中，MySQL只有在排序条件不是一个查询条件表达式的情况下才使用索引。
3.尽量不要在where中包含子查询。
关于时间的查询，尽量不要写成：where to_char(dif_date,’yyyy-mm-dd’)=to_char(‘2007-07-01′,’yyyy-mm-dd’);
4.在过滤条件中，可以过滤掉最大数量记录的条件必须放在where子句的末尾;
FROM子句中写在最后的表(基础表，driving table)将被最先处理，在FROM子句中包含多个表的情况下，你必须选择记录条数最少的表作为基础表。如果有三个以上的连接查询，
那就需要选择交叉表 (intersection table)作为基础表，交叉表是指那个被其他表所引用的表;
5.采用绑定变量。
6.在WHERE中尽量不要使用OR。
7.用EXISTS替代IN、用NOT EXISTS替代NOT IN;
8.避免在索引列上使用计算：WHERE SAL*12>25000;
9.用IN来替代OR： WHERE LOC_ID=10 OR LOC_ID=15 OR LOC_ID=20
10.避免在索引列上使用IS NULL和IS NOT NULL;
11.总是使用索引的第一个列;
12.用UNION-ALL替代UNION;
13.避免改变索引列的类型：SELECT…FROM EMP WHERE EMPNO=’123’，由于隐式数据类型转换，to_char(EMPNO)=’123’，因此，将不采用索引，一般在采用字符串拼凑动态SQL语句出现;
14.’!=’ 将不使用索引;
15.优化GROUP BY;
16.避免带有LIKE参数的通配符，LIKE ‘4YE%’使用索引，但LIKE ‘%YE’不使用索引
17.避免使用困难的正规表达式，例如select * from customer where zipcode like “98___”，即便在zipcode上建立了索引，在这种情况下也还是采用顺序扫描的方式。
如果把语句改成select * from customer where zipcode>”98000″，在执行查询时就会利用索引来查询，显然会大大提高速度;
18.尽量明确的完成SQL语句，尽量少让数据库工作。比如写SELECT语句时，需要把查询的字段明确指出表名。尽量不要使用SELECT *语句。组织SQL语句的时候，尽量按照数据库的习惯进行组织。
mysql的性能优化包罗甚广： 索引优化，查询优化，查询缓存，服务器设置优化，操作系统和硬件优化，应用层面优化（web服务器，缓存）等等。这里的记录的优化技巧更适用于开发人员，都是从网络上收集和自己整理的，主要是查询语句上面的优化，其它层面的优化技巧在此不做记录。
查询的开销指标：
执行时间 检查的行数 返回的行数
建立索引的几个准则：
1、合理的建立索引能够加速数据读取效率，不合理的建立索引反而会拖慢数据库的响应速度。
2、索引越多，更新数据的速度越慢。
3、尽量在采用MyIsam作为引擎的时候使用索引（因为MySQL以BTree存储索引），而不是InnoDB。但MyISAM不支持Transcation。
4、当你的程序和数据库结构/SQL语句已经优化到无法优化的程度，而程序瓶颈并不能顺利解决，那就是应该考虑使用诸如memcached这样的分布式缓存系统的时候了。 5、习惯和强迫自己用EXPLAIN来分析你SQL语句的性能。
- count的优化
比如：计算id大于5的城市 a. select count() from world.city where id > 5; b. select (select count() from world.city) – count() from world.city where id <= 5; a语句当行数超过11行的时候需要扫描的行数比b语句要多， b语句扫描了6行，此种情况下，b语句比a语句更有效率。当没有where语句的时候直接select count() from world.city这样会更快，因为mysql总是知道表的行数。
- 避免使用不兼容的数据类型。
例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。 在程序中，保证在实现功能的基础上，尽量减少对数据库的访问次数；通过搜索参数，尽量减少对表的访问行数,最小化结果集，从而减轻网络负担；能够分开的操作尽量分开处理，提高每次的响应速度；在数据窗口使用SQL时，尽量把使用的索引放在选择的首列；算法的结构尽量简单；在查询时，不要过多地使用通配符如 SELECT * FROM T1语句，要用到几列就选择几列如：SELECT COL1,COL2 FROM T1；在可能的情况下尽量限制尽量结果集行数如：SELECT TOP 300 COL1,COL2,COL3 FROM T1,因为某些情况下用户是不需要那么多的数据的。不要在应用中使用数据库游标，游标是非常有用的工具，但比使用常规的、面向集的SQL语句需要更大的开销；按照特定顺序提取数据的查找。
- 索引字段上进行运算会使索引失效。
尽量避免在WHERE子句中对字段进行函数或表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如： SELECT * FROM T1 WHERE F1/2=100 应改为: SELECT * FROM T1 WHERE F1=100*2
- 避免使用!=或＜＞、IS NULL或IS NOT NULL、IN ，NOT IN等这样的操作符.
因为这会使系统无法使用索引,而只能直接搜索表中的数据。例如: SELECT id FROM employee WHERE id != “B%” 优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。在in语句中能用exists语句代替的就用exists.
- 尽量使用数字型字段.
一部分开发人员和数据库管理人员喜欢把包含数值信息的字段 设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
- 合理使用EXISTS,NOT EXISTS子句。如下所示：
1.SELECT SUM(T1.C1) FROM T1 WHERE (SELECT COUNT()FROM T2 WHERE T2.C2=T1.C2>0) 2.SELECT SUM(T1.C1) FROM T1WHERE EXISTS(SELECT * FROM T2 WHERE T2.C2=T1.C2) 两者产生相同的结果，但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。如果你想校验表里是否存在某条纪录，不要用count()那样效率很低，而且浪费服务器资源。可以用EXISTS代替。如： IF (SELECT COUNT(*) FROM table_name WHERE column_name = ‘xxx’)可以写成：IF EXISTS (SELECT * FROM table_name WHERE column_name = ‘xxx’)
-
能够用BETWEEN的就不要用IN
-
能够用DISTINCT的就不用GROUP BY
-
尽量不要用SELECT INTO语句。SELECT INTO 语句会导致表锁定，阻止其他用户访问该表。
-
必要时强制查询优化器使用某个索引
SELECT * FROM T1 WHERE nextprocess = 1 AND processid IN (8,32,45) 改成： SELECT * FROM T1 (INDEX = IX_ProcessID) WHERE nextprocess = 1 AND processid IN (8,32,45) 则查询优化器将会强行利用索引IX_ProcessID 执行查询。
- 消除对大型表行数据的顺序存取
尽管在所有的检查列上都有索引，但某些形式的WHERE子句强迫优化器使用顺序存取。如： SELECT * FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008 解决办法可以使用并集来避免顺序存取： SELECT * FROM orders WHERE customer_num=104 AND order_num>1001 UNION SELECT * FROM orders WHERE order_num=1008 这样就能利用索引路径处理查询。【jacking 数据结果集很多，但查询条件限定后结果集不大的情况下，后面的语句快】
- 尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。
见如下例子： SELECT * FROM T1 WHERE NAME LIKE ‘%L%’ SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’ SELECT * FROM T1 WHERE NAME LIKE ‘L%’ 即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作，不要习惯性的使用 ‘%L%’这种方式(会导致全表扫描)，如果可以使用`L%’相对来说更好;
- 虽然UPDATE、DELETE语句的写法基本固定，但是还是对UPDATE语句给点建议：
a) 尽量不要修改主键字段。 b) 当修改VARCHAR型字段时，尽量使用相同长度内容的值代替。 c) 尽量最小化对于含有UPDATE触发器的表的UPDATE操作。 d) 避免UPDATE将要复制到其他数据库的列。 e) 避免UPDATE建有很多索引的列。 f) 避免UPDATE在WHERE子句条件中的列。
- 能用UNION ALL就不要用UNION
UNION ALL不执行SELECT DISTINCT函数，这样就会减少很多不必要的资源 在跨多个不同的数据库时使用UNION是一个有趣的优化方法，UNION从两个互不关联的表中返回数据，这就意味着不会出现重复的行，同时也必须对数据进行排序，我们知道排序是非常耗费资源的，特别是对大表的排序。 UNION ALL可以大大加快速度，如果你已经知道你的数据不会包括重复行，或者你不在乎是否会出现重复的行，在这两种情况下使用UNION ALL更适合。此外，还可以在应用程序逻辑中采用某些方法避免出现重复的行，这样UNION ALL和UNION返回的结果都是一样的，但UNION ALL不会进行排序。
- 字段数据类型优化：
a. 避免使用NULL类型：NULL对于大多数数据库都需要特殊处理，MySQL也不例外，它需要更多的代码，更多的检查和特殊的索引逻辑，有些开发人员完全没有意识到，创建表时NULL是默认值，但大多数时候应该使用NOT NULL，或者使用一个特殊的值，如0，-1作为默认值。 b. 尽可能使用更小的字段，MySQL从磁盘读取数据后是存储到内存中的，然后使用cpu周期和磁盘I/O读取它，这意味着越小的数据类型占用的空间越小，从磁盘读或打包到内存的效率都更好，但也不要太过执着减小数据类型，要是以后应用程序发生什么变化就没有空间了。修改表将需要重构，间接地可能引起代码的改变，这是很头疼的问题，因此需要找到一个平衡点。 c. 优先使用定长型
通过SQL调优提高查询性能最重要的就是对索引的使用，下面是对索引使用的一些总结，希望对你有所帮助。
MySQL索引对数据检索的性能至关重要，盲目的增加索引不仅不能带来性能的提升，反而会消耗更多的额外资源。
索引是用于快速查找记录的一种数据结构。索引就像是数据库中数据的目录，数据库在查询时，首先在索引中找到匹配的值，然后根据这个匹配值找到对应的数据行。
聚簇索引的顺序就是数据的物理存储顺序，索引中数据域存储的就是实际的数据，一个表最多只能有一个聚簇索引，适用于查询多行数据，不适用于频繁修改的列，一般在主键上创建。
非聚簇索引顺序与数据物理排列顺序无关，索引中存储的内容为实际数据的地址，适应于查询单行数据。
普通索引，即平时创建的普通索引。
唯一索引，索引所在的列或列组合的值是全表唯一的。
全文索引，MySQL从3.23.23版开始支持全文索引，它查找的是文中的关键词，而不是直接比较索引中的值。
单列索引，在单列上创建的索引。
组合索引，在多个列上创建的索引。
最左前缀查找：where子句中有a、b、c三个查询条件，创建一个组合索引abc(a,b,c)，最左前缀的概念是说以组合索引最左边的列a组合成的查询条件，如(a,b,c)、(a,b)、(a,c)，这三种情况的查询条件都会使用abc索引，和where子句中a、b、c出现的顺序没关系，可以是where c=? and b=? and a=?，但(b,c)组合不会使用索引，即where c=? and b=?。
哪些列适合创建索引：
1.经常作为查询条件的列；
2.经常作为排序条件的列；
3.经常作为join条件的列；
4.经常被查询的列。
哪些列不适合创建索引：
1.数据频繁被修改的列，数据被修改，索引需要做相应的修改，消耗资源； 2.区分度不是很高的列，如性别，列值重复性太大，索引效果不是很明显； 3.不是经常被作为查询条件、排序条件、连接条件的列。
经验总结：
1.列上进行函数计算将不会使用索引；
2.对于创建索引的列，避免存储NULL，NULL会使索引更加复杂、效率变低，可以使用NOT NULL进行约束；
3.对于模糊查询like ‘%abc%’，将不会使用索引，而like 'abc%'将会使用索引；
4.对于not in、not exists、!=等负向查询将不会使用索引；
5.每次查询只使用一个索引，如果where条件使用了索引，order by将不再使用索引；
6.对于where子句中有多个查询条件的，单列索引的效率不如复合索引，因为查询每次只能使用一个索引；
7.MySQL只对以下操作符才使用索引：<、<=、=、>、>=、between、in，但是需要注意in的范围值不要太多；
8.union all可以使用索引，但本身效率不是很高，不建议使用；
9.列上进行类型转换的将不会使用索引；
10.老版本MySQL对OR条件不使用索引，新版本才支持，不建议使用OR。
提供者：个人之家，http://www.hao123m.com/sitemap.html
转载请备注来源，好的话记得收藏哦
5754
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
