MySQL大数据高并发处理之-查询的优化

发布时间：2022-11-28 11:50:36 所属栏目：大数据来源：

导读：　　接上一章的内容,我们来谈一下MySQL中的查询优化技术。保证在实现功能的基础上，尽量减少对数据库的访问次数(可以用缓存保存查询结果，减少查询次数)；通过搜索参数，尽量减少对表的访问行数,最小化结果集，从而减

　　接上一章的内容,我们来谈一下MySQL中的查询优化技术。保证在实现功能的基础上，尽量减少对数据库的访问次数(可以用缓存保存查询结果，减少查询次数)；通过搜索参数，尽量减少对表的访问行数,最小化结果集，从而减轻网络负担；能够分开的操作尽量分开处理，提高每次的响应速度；在数据窗口使用SQL时，尽量把使用的索引放在选择的首列；算法的结构尽量简单；在查询时，不要过多地使用通配符如 * FROM T1语句，要用到几列就选择几列如：,COL2 FROM T1；在可能的情况下尽量限制尽量结果集行数如： TOP 300 COL1,COL2,COL3 FROM T1,因为某些情况下用户是不需要那么多的数据的。

　　在没有建索引的情况下，数据库查找某一条数据，就必须进行全表扫描了，对所有数据进行一次遍历，查找出符合条件的记录。在数据量比较小的情况下，也许看不出明显的差别，但是当数据量大的情况下，这种情况就是极为糟糕的了。

　　SQL语句在SQL 中是如何执行的，他们担心自己所写的SQL语句会被SQL 误解。比如：

　　* from where name='' and tID > 10000 和执行:

　　* from where tID > 10000 and name=''

　　一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的10000条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个name=''的，而后再根据限制条件条件tID>10000来提出查询结果。

　　事实上，这样的担心是不必要的。SQL 中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。虽然查询优化器可以根据where子句自动的进行查询优化mysql大数据查询优化，但有时查询优化器就会不按照您的本意进行快速查询。

　　在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，并且可以利用索引快速获得所需数据。

　　SARG的定义：用于限制搜索的一个操作，因为它通常是指一个特定的匹配，一个值的范围内的匹配或者两个以上条件的AND连接。形式如下：

　　列名操作符或操作符列名

　　列名可以出现在操作符的一边，而常数或变量出现在操作符的另一边。如：

　　Name=’张三’

　　价格>5000

　　如果一个表达式不能满足SARG的形式，那它就无法限制搜索的范围了，也就是SQL 必须对每一行都判断它是否满足WHERE子句中的所有条件。所以一个索引对于不满足SARG形式的表达式来说是无用的。

　　所以，优化查询最重要的就是，尽量使语句符合查询优化器的规则避免全表扫描而使用索引查询。

　　具体要注意的：

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

　　id from t where num is null

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

　　id from t where num=0

　　2.应尽量避免在 where 子句中使用!=或操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。

　　3.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：

　　id from t where num=10 or num=20

　　可以这样查询：

　　id from t where num=10

　　union all

　　id from t where num=20

　　4.in 和 not in 也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如：

　　id from t where num in(1,2,3)

　　对于连续的数值，能用就不要用 in 了：

　　id from t where num 1 and 3

　　5.尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。

　　见如下例子：

　　* FROM T1 WHERE NAME LIKE ‘%L%’

　　* FROM T1 WHERE (NAME,2,1)=’L’

　　* FROM T1 WHERE NAME LIKE ‘L%’

　　即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。

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

　　id from t where num=@num

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

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

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

　　* FROM T1 WHERE F1/2=100

　　应改为:

　　* FROM T1 WHERE F1=100*2

　　* FROM WHERE (,1,4)=’5378’

　　应改为:

　　* FROM WHERE LIKE ‘5378%’

　　, , FROM

　　WHERE (yy,,()) > 21

　　应改为:

　　, , FROM

　　WHERE < (yy,-21,())

　　即：任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。

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

　　id from t where (name,1,3)='abc'--name以abc开头的id

　　id from t where (day,,'2005-11-30')=0--‘2005-11-30’生成的id

　　应改为:

　　id from t where name like 'abc%'

　　id from t where >='2005-11-30' and )

　　SUM(T1.C1) FROM (

　　* FROM T2 WHERE T2.C2=T1.C2)

　　两者产生相同的结果，但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。

　　如果你想校验表里是否存在某条纪录，不要用count(*)那样效率很低，而且浪费服务器资源。可以用代替。如：

　　IF ( COUNT(*) FROM WHERE = 'xxx')

　　可以写成：

　　IF ( * FROM WHERE = 'xxx')

　　经常需要写一个T_SQL语句比较一个父结果集和子结果集，从而找到是否存在在父结果集中有而在子结果集中没有的记录，如：

　　a. FROM a---- tbl a 表示tbl用别名a代替

　　WHERE NOT ( * FROM b WHERE a. = b.)

　　a. FROM a

　　LEFT JOIN b ON a. = b. WHERE b. IS NULL

　　FROM

　　WHERE NOT IN ( FROM )

　　三种写法都可以得到同样正确的结果，但是效率依次降低。

　　12.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。

　　13.避免频繁创建和删除临时表，以减少系统表资源的消耗。

　　14.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。

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

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

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

　　18.尽量避免大事务操作，提高系统并发能力。

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

　　20. 避免使用不兼容的数据类型。例如float和int、char和、和是不兼容的（条件判断时）。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如:

　　name FROM WHERE > 60000

　　在这条语句中,如字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。

　　21.充分利用连接条件（条件越多越快），在某种情况下，两个表之间可能不只一个的连接条件，这时在 WHERE 子句中将连接条件完整的写上，有可能大大提高查询速度。

　　例：

　　SUM(A.) FROM A,CARD B WHERE A. = B.

　　SUM(A.) FROM A,CARD B WHERE A. = B. AND A.=B.

　　第二句将比第一句执行快得多。

　　22、使用视图加速查询

　　把表的一个子集进行排序并创建视图，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如：

　　cust.name，.，……other

　　FROM cust，

　　WHERE cust. = .

　　AND .>0

　　AND cust.>“98000”

　　ORDER BY cust.name

　　如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个视图中，并按客户的名字进行排序：

　　VIEW DBO.

　　AS

　　cust.name，.，……other

　　FROM cust，

　　WHERE cust. = .

　　AND .>0

　　ORDER BY cust.name

　　然后以下面的方式在视图中查询：

　　＊ FROM

　　WHERE >“98000”

　　视图中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。

　　23、能用的就不用GROUP BY （group by 操作特别慢）

　　FROM WHERE > 10 GROUP BY

　　可改为：

　　FROM WHERE > 10

　　24.能用UNION ALL就不要用UNION

　　UNION ALL不执行函数，这样就会减少很多不必要的资源

　　35.尽量不要用 INTO语句。

　　INOT 语句会导致表锁定，阻止其他用户访问该表。

　　上面我们提到的是一些基本的提高查询速度的注意事项,但是在更多的情况下,往往需要反复试验比较不同的语句以得到最佳方案。最好的方法当然是测试，看实现相同功能的SQL语句哪个执行时间最少，但是数据库中如果数据量很少，是比较不出来的，这时可以用查看执行计划，即：把实现相同功能的多条SQL语句考到查询分析器，按CTRL+L看查所利用的索引，表扫描次数（这两个对性能影响最大），总体上看询成本百分比即可

（编辑：PHP编程网 - 襄阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

数据分析常见的误区有	远程访问装有GPU的电脑
数据驱动业务的18个有	科技化应用雷达互动投