1.对查询举行优化，应只管防止全表扫描，起首应斟酌在 where 及 order by 触及的列上竖立索引。
2.应只管防止在 where 子句中对字段举行 null 值推断，不然将致使引擎摒弃运用索引而举行全表扫描，如：select id from t where num is null 能够在 num 上设置默认值 0，确保表中 num 列没有 null 值，然后如许查询：select id from t where num=0
3.应只管防止在 where 子句中运用!=或<>操纵符，不然引擎将摒弃运用索引而举行全表扫描。
4.应只管防止在 where 子句中运用 or 来衔接前提，不然将致使引擎摒弃运用索引而举行全表扫描，如：select id from t where num=10 or num=20 能够如许查询：select id from t where num=10 union all select id from t where num=20
5.in 和 not in 也要慎用，不然会致使全表扫描，如：select id from t where num in(1,2,3) 关于一连的数值，能用 between 就不要用 in 了：select id from t where num between 1 and 3
6.下面的查询也将致使全表扫描：select id from t where name like '%李%' 若要进步效力，能够斟酌全文检索。
7.假如在 where 子句中运用参数，也会致使全表扫描。由于 SQL 只要在运行时才会剖析局部变量，但优化递次不能将接见设想的挑选推晚到运行时；它必需在编译时举行挑选。然则，假如在编译时竖立接见设想，变量的值照样未知的，因此没法作为索引挑选的输入项。如下面语句将举行全表扫描：select id from t where num=@num 能够改成强迫查询运用索引：select id from t with(index(索引名)) where num=@num
8.应只管防止在 where 子句中对字段举行表达式操纵，这将致使引擎摒弃运用索引而举行全表扫描。如：select id from t where num/2=100 应改成: select id from t where num=100*2。
9.应只管防止在 where 子句中对字段举行函数操纵，这将致使引擎摒弃运用索引而举行全表扫描。如：select id from t where substring(name,1,3)='abc' ，name 以 abc 开头的 id 应改成:select id from t where name like ‘abc%'。
10.不要在 where 子句中的 “=” 左侧举行函数、算术运算或其他表达式运算，不然体系将大概没法准确运用索引。
11.在运用索引字段作为前提时，假如该索引是复合索引，那末必需运用到该索引中的第一个字段作为前提时才保证体系运用该索引，不然该索引将不会被运用，而且应只管的让字段递次与索引递次相一致。
12.不要写一些没有意义的查询，如须要生成一个空表构造：select col1,col2 into #t from t where 1=0, 这类代码不会返回任何结果集，然则会斲丧体系资本的，应改成如许：create table #t(…)。
13.许多时刻用 exists 替代 in 是一个好的挑选：select num from a where num in(select num from b)，用下面的语句替代：select num from a where exists(select 1 from b where num=a.num)。
14.并非一切索引对查询都有用，SQL 是依据表中数据来举行查询优化的，当索引列有大批数据反复时，SQL 查询大概不会去运用索引，如一表中有字段 sex，male、female 险些各一半，那末纵然在 sex 上建了索引也对查询效力起不了作用。
15.索引并非越多越好，索引当然能够进步响应的 select 的效力，但同时也下降了 insert 及 update 的效力，由于 insert 或 update 时有大概会重修索引，所以如何建索引须要慎重斟酌，视细致情况而定。一个表的索引数 最好不要凌驾6个，若太多则应斟酌一些不常运用到的列上建的索引是不是有必要。
16.应只管的防止更新 clustered 索引数据列，由于 clustered 索引数据列的递次就是表纪录的物理存储递次，一旦该列值转变将致使全部表纪录的递次的调解，会消耗相当大的资本。若运用体系须要频仍更新 clustered 索引数据列，那末须要斟酌是不是应将该索引建为 clustered 索引。
17.只管运用数字型字段，若只含数值信息的字段只管不要设想为字符型，这会下降查询和衔接的机能，并会增添存储开支。这是由于引擎在处置惩罚查询和衔接时会逐一比较字符串中每一个字符，而关于数字型而言只须要比较一次就够了。
18.只管的运用 varchar/nvarchar 替代 char/nchar，由于起首变长字段存储空间小，能够节约存储空间，其次关于查询来讲，在一个相对较小的字段内搜刮效力明显要高些。
19.任何地方都不要运用 select * from t，用细致的字段列表替代 “*”，不要返回用不到的任何字段。
20.只管运用表变量来替代暂时表。假如表变量包含大批数据，请注意索引异常有限（只要主键索引）。
21.防止频仍创建和删除暂时表，以削减体系表资本的斲丧。
22.暂时表并非不可运用，适当地运用它们能够使某些例程更有用，比方，当须要反复援用大型表或经常使用表中的某个数据集时。然则，关于一次性事宜，最好运用导出表。
23.在新建暂时表时，假如一次性插进去数据量很大，那末能够运用 select into 替代 create table，防止形成大批 log ，以进步速率；假如数据量不大，为了紧张体系表的资本，应先 create table，然后 insert。
24.假如运用到了暂时表，在存储历程的末了务势必一切的暂时表显式删除，先 truncate table，然后 drop table，如许能够防止体系表的较长时候锁定。
25.只管防止运用游标，由于游标的效力较差，假如游标操纵的数据凌驾1万行，那末就应当斟酌改写。
26.运用基于游标的要领或暂时表要领之前，应先寻觅基于集的解决方案来解决问题，基于集的要领一般更有用。
27.与暂时表一样，游标并非不可运用。对小型数据集运用 FAST_FORWARD 游标一般要优于其他逐行处置惩罚要领，尤其是在必需援用几个表才取得所需的数据时。在结果集合包含“算计”的例程一般要比运用游标实行的速率快。假如开发时候许可，基于游标的要领和基于集的要领都能够尝试一下，看哪一种要领的结果更好。
28.在一切的存储历程和触发器的入手下手处设置 SET NOCOUNT ON，在结束时设置 SET NOCOUNT OFF。无需在实行存储历程和触发器的每一个语句后向客户端发送 DONE_IN_PROC 音讯。
29.只管防止大事件操纵，进步体系并发才能。
30.只管防止向客户端返回大数据量，若数据量过大，应当斟酌响应需求是不是合理。
以上就是MySQL 万万级大数据 SQL 查询优化技能详解的细致内容，更多请关注ki4网别的相干文章！
