网上关于SQL优化的教程很多，但是比较乱。最近有时间整理一下，写出来分享给大家。如有错误和不足，敬请指正和补充。我花了很多时间查找资料，修改，排版这篇文章。希望大家看完之后，如果觉得不错，推荐给更多的人，让更多的人看到，指正，补充。1.优化查询，尽量避免全表扫描，首先考虑对where和orderby涉及的列建立索引。2.尽量避免在where子句中判断字段为空值，否则引擎会放弃使用索引，进行全表扫描，如：selectidfromtwherenumisnull最好不要离开NULL为数据库，尽可能使用NOTNULL来填充数据库。备注、说明、评论等可以设置为NULL，其他的最好不要使用NULL。不要以为NULL不需要空间，例如：char(100)类型，在创建字段时，空间是固定的，无论是否插入值（也包括NULL），都会占用空间100个字符，如果是varchar这样的变长字段，null不占空间。可以给num设置默认值0，保证表中num列没有空值，然后这样查询：selectidfromtwherenum=03。尽量避免使用!=或<>运算符在where子句中，否则引擎会放弃索引的使用而进行全表扫描。4.尽量避免在where子句中使用or连接条件。如果一个字段有索引，另一个没有，会导致引擎放弃使用索引，进行全表扫描，如：selectidfromtwherenum=10orName='admin'可以查询像这样：selectidfromtwherenum=10unionallselectidfromtwhereName='admin'5.in和notin也要慎用，否则会导致全表扫描，如：selectidfromtwherenumin(1,2,3)对于连续值，如果可以使用between就不要用in：selectidfromtwherenumbetween1and3很多时候用exists代替in是个不错的选择：selectnumfromawherenumin(selectnumfromb)替换为以下语句：selectnumfromawhereexists(select1frombwherenum=a.num)6.下面的查询也会得到一个全表scan:selectidfromtwherenamelike'%abc%'如果想提高效率，可以考虑全文搜索。7、如果where子句中使用了参数，也会造成全表扫描。因为SQL只在运行时解析局部变量，所以优化器不能将访问计划的选择推迟到运行时；它必须在编译时选择。但是，如果访问计划是在编译时建立的，变量的值仍然是未知的，因此不能用作索引选择的输入。例如，下面的语句将执行全表扫描：selectidfromtwherenum=@num可以更改为强制查询使用索引：selectidfromtwith(index(indexname))wherenum=@数尽量避免在wheresub语句中对字段进行表达式操作，会导致引擎放弃使用索引而进行全表扫描。例如：selectidfromtwherenum/2=100应改为：selectidfromtwherenum=100*29。应该尽量避免在where子句中对字段进行函数式操作，这样会导致引擎放弃使用索引而进行全表扫描。例如：selectidfromtwheresubstring(name,1,3)='abc'---id以abc开头的nameselectidfromtwheredatediff(day,createdate,'2005-11-30')=0-–'2005-11-30'--生成的id应该改为：selectidfromtwherenamelike'abc%'selectidfromtwherecreatedate>='2005-11-30'andcreatedate<'2005-12-1'10。请勿在where子句中对“=”左侧进行函数、算术运算或其他表达式操作，否则系统可能无法正确使用索引。11、使用索引字段作为条件时，如果索引是复合索引，那么必须以索引中的第一个字段作为条件，保证系统使用索引，否则索引不会被使用，应该be使字段顺序尽可能与索引顺序一致。12、不要写一些无意义的查询。如果需要生成空表结构：selectcol1,col2into#tfromtwhere1=0这种代码不会返回任何结果集，但是会消耗系统资源，应该改成这样：createtable#t(…)13.update语句，如果只改变1或2个字段，不要更新所有字段，否则频繁调用会造成明显的性能消耗，同时带来大量日志。14.多张数据量大的表的JOIN（这里以几百条为大），必须先分页再JOIN，否则逻辑读会很高，性能很差。15.从表中选择计数(*)；这种不带任何条件的计数会造成全表扫描，没有业务意义，必须剔除。16、索引越多越好，索引可以提高对应select的效率，但是也会降低insert和update的效率，因为insert或者update的时候可能会重建索引，所以需要如何建立索引仔细考虑。视情况可以是。一张表中的索引最好不要超过6个。如果过多，则应考虑是否有必要在一些不常用的列上建立索引。17、尽量避免更新聚簇索引数据列，因为聚簇索引数据列的顺序就是表记录的物理存储顺序。一旦该列的值发生变化，整个表记录的顺序就会随之调整，这会消耗相当大的资源。如果应用系统需要频繁更新聚簇索引数据列，那么就需要考虑是否将索引构建为聚簇索引。18.尝试使用数字字段。如果只包含数字信息的字段尽量不要设计成字符类型，这样会降低查询和连接的性能，还会增加存储开销。这是因为引擎在处理查询和连接时，会把字符串中的每个字符一个一个地进行比较，但是对于数字类型，只需要一个比较就可以了。19、尽量使用varchar/nvarchar而不是char/nchar，因为一来变长字段的存储空间小，可以节省存储空间，二来对于查询来说，在比较小的字段内查找效率显然更高。20、不要在任何地方使用selectfromt，将“”替换为特定的字段列表，不要返回任何未使用的字段。21.尽量使用表变量代替临时表。如果您的表变量包含大量数据，请注意索引非常有限（仅主键索引）。避免频繁创建和删除临时表，减少系统表资源的消耗。临时表并不是不可用，适当地使用它们可以使某些例程更高效，例如，当需要重复引用大表或常用表中的数据集时。但是，对于一次性事件，最好使用导出表。23、新建临时表时，如果一次性插入大量数据，可以用selectinto代替createtable，避免创建大量日志，提高速度；如果数据量不大，为了缓解系统表的资源，应该先建表，再插入。24、如果使用临时表，必须在存储过程结束时显式删除所有临时表，先truncatetable，再droptable，避免系统表长期锁定。25、尽量避免使用游标，因为游标的效率很低。如果游标操作的数据超过10000行，那么就要考虑重写了。26.在使用基于游标的方法或临时表方法之前，应该先找到基于集合的方法来解决问题，而基于集合的方法通常更有效。27.和临时表一样，游标也不是不可用。在小型数据集上使用FAST_FORWARD游标通常优于其他逐行处理方法，尤其是在必须引用多个表才能获取所需数据的情况下。在结果集中包含Total的例程通常比使用游标更快。如果开发时间允许，可以同时尝试基于游标的方法和基于集合的方法，看看哪种方法效果更好。28.在所有存储过程和触发器的开头设置SETNOCOUNTON，在结束时设置SETNOCOUNTOFF。存储过程和触发器的每条语句执行完后，不需要向客户端发送DONE_IN_PROC消息。29、尽量避免大事务操作，提高系统并发度。30、尽量避免向客户端返回大量数据。如果数据量太大，就要考虑对应的需求是否合理。实际案例分析：拆分大型DELETE或INSERT语句，批量提交SQL语句 如果您需要在在线网站上执行大型DELETE或INSERT查询，您需要非常小心，避免您的操作让您整个站点停止响应。因为这两个操作都会锁表，一旦表被锁住，其他操作就无法进入。 Apache会有很多子进程或线程。因此，它的工作效率相当高，我们的服务器不希望有太多的子进程、线程和数据库连接，占用大量的服务器资源，尤其是内存。 如果你锁表一段时间，比如30秒，那么对于一个流量大的站点来说，这30秒累计的访问进程数/线程数、数据库连接数、打开文件数，可能不仅让你的WEB服务崩溃，还可能导致你的整个服务器立即挂掉。 所以，如果你有一个大进程，你必须拆分它，使用LIMIToracle(rownum),sqlserver(top)条件是一个很好的方法。下面是mysql的例子：复制代码while(1){ //一次只做1000条记录 mysql_query("deletefromlogswherelog_date<='2012-11-01'limit1000"); if(mysql_affected_rows()==0){ //删除完成，退出！ 休息； }
