❶ 大数据干货：sql优化方案精解十则
一、避免进行null判断
应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，这里最好不要给数据库留NULL，尽可能的使用 NOT NULL填充数据库。
备注、描述、评论之类的可以设置为 NULL，最好不要使用NULL。不要错误的认为NULL 不需要空间，如char(100) 型，在字段建立时，空间就固定了。不管是否插入值(NULL也包含在内)，都是占用 100个字符的空间的，如果是varchar这样的变长字段， null 不占用空间。可以在num上设置默认值0，确保表中num列没有null值。
二、不要使用select *
使用select *的话会增加解析的时间，另外也会把不需要的数据同时查询出来，从而延长数据传输时间，耗费精力。如text类型的字段，通常用来保存一些内容比较繁杂的东西，如果使用select *，则会把该字段也查询出来。
三、谨慎使用模糊查询
当模糊匹配以%开头时，该列索引将失效。若不以%开头，该列索引有效。
四、不要使用列号
使用列号的话，将会增加不必要的解析时间。
五、优先使用UNION ALL，避免使用UNION
因为UNION 会将各查询子集的记录做比较，故比起UNION ALL ，通常速度都会慢上许多。一般来说，如果使用UNION ALL能满足要求的话，务必使用UNION ALL。还有一种情况，如果业务上能够确保不会出现重复记录。
六、在where语句或者order by语句中避免对索引字段进行计算操作
当在索引列上进行操作之后，索引将会失效。正确做法应该是将值计算好再传入进来。
七、使用not exist代替not in
如果查询语句使用了not in 那么内外表都进行全表扫描，没有用到索引;而not extsts 的子查询依然能用到表上的索引。
八、exist和in的区别
in 是把外表和内表作hash 连接，而exists是对外表作loop循环，每次loop循环
再对内表进行查询。因此，in用到的是外表的索引， exists用到的是内表的索引。如果查询的两个表大小相当，那么用in和exists差别不大。如果两个表中一个较小，一个是大表，则子查询表大的用exists，子查询表小的用in。
九、避免在索引列上做如下操作
1.避免在索引列上使用IS NULL和IS NOT NULL。
2.避免在索引列上出现数据类型转换。(比如某字段是String类型，参数传入时是int类型)当在索引列上使用如上操作时，索引将会失效，造成全表扫描。
十、复杂操作可以考虑适当拆成几步
有时候会有通过一个SQL语句来实现复杂业务的例子出现，为了实现复杂的业务，嵌套多级子查询。造成SQL性能问题。对于这种情况可以考虑拆分SQL，通过多个SQL语句实现，或者把部分程序能完成的工作交给程序完成。
❷ SQL Server数据库的高性能优化经验总结
本文主要向大家介绍的是正确优化SQL
Server数据库的经验总结，其中包括在对其进行优化的实际操作中值得大家注意的地方描述，以及对SQL语句进行优化的最基本原则，以下就是文章的主要内容描述。
优化数据库的注意事项：
1、关键字段建立索引。
2、使用存储过程，它使SQL变得更加灵活和高效。
3、备份数据库和清除垃圾数据。
4、SQL语句语法的优化。(可以用Sybase的SQL
Expert，可惜我没找到unexpired的序列号)
5、清理删除日志。
SQL语句优化的基本原则：
1、使用索引来更快地遍历表。
缺省情况下建立的索引是非群集索引，但有时它并不是最佳的。在非群集索引下，数据在物理上随机存放在数据页上。合理的索引设计要建立在对各种查询的分析和预测上。
一般来说：
①.有大量重复值、且经常有范围查询(between,
>,<
，>=,<
=)和order
by、group
by发生的列，可考虑建立群集索引
②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引;
③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。
2、IS
NULL
与
IS
NOT
NULL
不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何在where子句中使用is
null或is
not
null的语句优化器是不允许使用索引的。
3、IN和EXISTS
EXISTS要远比IN的效率高。里面关系到full
table
scan和range
scan。几乎将所有的IN操作符子查询改写为使用EXISTS的子查询。
4、在海量查询时尽量少用格式转换。
5、当在SQL
SERVER
2000中
如果存储过程只有一个参数，并且是OUTPUT类型的，必须在调用这个存储过程的时候给这个参数一个初始的值，否则会出现调用错误。
6、ORDER
BY和GROPU
BY
使用ORDER
BY和GROUP
BY短语，任何一种索引都有助于SELECT的性能提高。注意如果索引列里面有NULL值，Optimizer将无法优化。
7、任何对列的操作都将导致表扫描，它包括SQL
Server数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
8、IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。
9、SET
SHOWPLAN_ALL>10、谨慎使用游标
在某些必须使用游标的场合，可考虑将符合条件的数据行转入临时表中，再对临时表定义游标进行操作，这样可使性能得到明显提高。
注释：所谓的优化就是WHERE子句利用了索引，不可优化即发生了表扫描或额外开销。经验显示，SQL
Server数据库性能的最大改进得益于逻辑的数据库设计、索引设计和查询设计方面。反过来说，最大的性能问题常常是由其中这些相同方面中的不足引起的。
其实SQL优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及SQL
Server数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。
❸ 如何进行SQL性能优化
这里分享下mysql优化的几种方法。
1、首先在打开的软件中，需要分别为每一个表创建 InnoDB FILE的文件。
❹ SQL优化（二）
SQL优化一： sql优化（一）
上片文章已经详细介绍了explain各个字段的含义，以及什么情况应该建立索引，什么情况不需要建立索引以及sql语句性能的判断依据，接下来我介绍下如何合理的建立索引。
sql语句：select id，author_id from article where category_id = 1 and comments>1 order by views desc limit 1;
分析：首先我们根据where后面的条件建立符合索引，然后根据order by后面的字段建立索引，因此建立索引idx_article_ccv，即以（category_id，comments，views）数据列建立复合索引，但由于comments是一个范围，按照BTree索引的原理，先排序category_id,如果遇到相同的category_id则再排序comments，如果遇到相同的comments则再排序views，又因为comments字段在复合索引里处于中间位置，而comments>1是一个条件（是一个范围值），在复合索引的一个范围值的数据列后面的索引全部失效，mysql无法利用索引再对后面的views部分进行检索，也就是说views无法按照索引排序，所以explain下此sql语句，type为range，extra使用的是Using filesort，这是比较糟糕的。所以我们放弃comments这个范围字段，建立索引idx_article_cv，即以（category_id，views）数据列建立复合索引，explain 此sql，type变成了ref，extra的using filesort也变成了using index，这就变得好多了。
索引：idx_article_cv，即以（category_id，views）数据列建立复合索引
前段时间做了一个销售精细化项目，是公司crm项目的一个大模块，大致就是为销售人员制定指标，实现销售目标从区域到团到业务员到客户，实时跟踪业务员所负责客户的下单量的情况。这就存在许多关联关系，区域-团，团-业务员，业务员-客户，这使得sql常常需要关联多张表。
sql语句：SELECT
tu.fuserid,
tu.faccount,
tu.fphone,
tu.fcertificationtype,
tu.fcertificatename,
tu.fkeyarea,
tu.fkeyareatext,
DATE_FORMAT(tcr.fupdatetime,'%Y-%m-%d %H:%i:%s') as fupdatetime,
tag.forggroupid,
tag.forggroupname,
tug.forguserid,
tug.fusername,
tug.fuserphone,
tag.fcitycode
FROM t_finedt_user AS tu
LEFT JOIN t_finedt_customer_relation AS tcr
ON tu.fuserid = tcr.fuserid
LEFT JOIN t_finedt_usergroup AS tug
ON tcr.forguserid = tug.forguserid
and tcr.forggroupid = tug.forggroupid
LEFT JOIN t_finedt_areagroup AS tag
ON tug.forggroupid = tag.forggroupid
where tu.fkeyarea=? and tu.fuserid=? and tug.forggroupid = ?
分析：上面的sql是左连接，左边的表一定是全表查询，所以要建立右边表对应关联字段的索引，在表t_finedt_user上建立tu_fuserid_fkeyarea索引，即以(fuserid，fkeyarea)字段建立索引，在表t_finedt_customer_relation 上建立tcr_forguserid_forggroupid索引，即以（forguserid，forggroupid）字段建立索引，在表t_finedt_usergroup 上建立tug_forguserid_forggroupid索引，即以（forguserid,forggroupid)字段建立索引，在表t_finedt_areagroup上建立tag_forggroupid索引，即以（forggroupid)字段建立索引。建立索引后，sql查询速度明显快了很多
索引：tcr_forguserid_forggroupid，tu_fuserid_fkeyarea，tug_forguserid_forggroupid，tag_forggroupid
1、尽可能减少join语句中的NestedLoop的循环次数，永远用小结果集驱动大结果集
2、优先优化NestedLoop的内层循环
3、保证join语句总被驱动表上的join字段已经被索引
4、当无法保证被驱动表join条件字段被索引，且内存资源充足的前提下，不要太吝啬joinBuffer的设置
1、全值匹配我最爱
2、最佳左前缀原则——如果索引了多列，要遵守最左前缀原则，指的是查询从索引的最左前列开始并且不跳过索引中的列
3、并在索引列上做任何操作（计算、函数、自动or手动类型转换），这些会导致索引失效而转向全表扫描
4、存储引擎不能使用索引中范围条件右边的列，范围之后的索引全失效
5、尽量使用覆盖索引（之访问索引的查询（索引列和查询的列一致）），减少select *
6、mysql在使用不等于（！=、>、<）的时候无法使用索引会导致全表扫描。
7、is null、is not null也无法使用索引。
8、like以通配符开头（"%abc.."），mysql索引失效也会变成全表扫描的操作。
9、字符串不加单引号也会引起索引失效
10、少用or，用它来连接时会索引失效。
1、对于单值索引，尽量选择针对当前query过滤性更好的索引
2、在选择组合索引的时候，当前query中过滤性最好的字段在索引字段顺序中，位置越靠前越好
3、在选择组合索引的时候，尽量选择尽可能包含当前query中的where字句中更多字段的索引
4、尽可能通过分析统计信息和调整query的写法来达到选择合适索引的目的。
全值匹配我最爱，最左前缀要遵守
带头大哥不能死，中间兄弟不能断
索引列上少计算，范围之后全失效
like百分写最右，覆盖索引不写里
不等空值还有or，索引失效要少用
var引号不可丢，sql高级也不难
❺ sql语句性能如何优化
如何加快查询速度?
1、升级硬件
2、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。
3、扩大服务器的内存
4、增加服务器CPU个数
5、对于大的数据库不要设置数据库自动增长，它会降低服务器的性能
6、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担降低性能。如果表很大，在表扫描的期间将表锁住，禁止其他的联接访问表,后果严重。
7、查询时不要返回不需要的行、列
8、用select
top
100
/
10
Percent
来限制用户返回的行数或者SET
ROWCOUNT来限制操作的行
9、在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数
10、一般在GROUP
BY
个HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：
select的Where字句选择所有合适的行，Group
By用来分组个统计行，Having字句用来剔除多余的分组。这样Group
By
个Having的开销小，查询快.对于大的数据行进行分组和Having十分消耗资源。如果Group
BY的目的不包括计算，只是分组，那么用Distinct更快
11、一次更新多条记录比分多次更新每次一条快,就是说批处理好
❻ 数据库牛人是如何进行SQL优化的
SQL 查询优化减少了查询所需的资源并提高了整体系统性能，在本文中，我们将讨论 SQL 查询优化、它是如何完成的、最佳实践及其重要性。
SQL 查询优化是编写高效的 SQL 查询，并在执行时间和数据库表示方面 提高查询性能 的迭代过程，查询优化是几个关系数据库管理系统 (RDBMS) 的一项重要功能。
查询是对来自数据库的数据或信息的问题或请求，需要编写一组数据库可以理解的预定义代码，结构化查询语言 (SQL) 和其他查询语言旨在检索或管理关系数据库中的数据。
数据库中的查询可以用许多不同的结构编写，并且可以通过不同的算法执行，写得不好的查询会消耗更多的系统资源，执行时间长，并可能导致服务损失，一个完美的查询可以减少执行时间并带来最佳的 SQL 性能。
SQL查询优化的主要目的是：
确保查询处于最佳路径和形式非常重要，SQL 查询过程需要最好的执行计划和计算资源，因为它们是 CPU 密集型操作，SQL 查询优化通过三个基本步骤完成：
解析确保查询在语法和语义上都是正确的，如果查询语法正确，则将其转换为表达式并传递到下一步。
优化在查询性能中扮演着重要的角色，并且可能很困难，任何考虑优化的查询执行计划都必须返回与之前相同的结果，但优化后的性能应该会有所提高。
SQL 查询优化包括以下基本任务：
最后，查询执行涉及将查询优化步骤生成的计划转化为操作，如果没有发生错误，此步骤将返回结果给用户。
一旦用户确定某个查询需要改进以优化 SQL 性能，他们就可以选择任何优化方法——优化 SQL 查询性能的方法有很多种，下面介绍了一些最佳实践。
提高查询性能的一种简单方法是将 SELECT * 替换为实际的列名，当开发人员在表中使用 SELECT * 语句时，它会读取每一列的可用数据。
使用 SELECT 字段名 FROM 而不是 SELECT * FROM 时，可以缩小查询期间从表中提取的数据的范围，这有助于提高查询速度。
循环中的 SQL 查询运行不止一次，这会显着降低运行速度，这些查询会不必要地消耗内存、CPU 能力和带宽，这会影响性能，尤其是当 SQL 服务器不在本地计算机上时，删除循环内的查询可提高整体查询性能。
使用SQL 服务器索引可以减少运行时间并更快地检索数据，可以使用聚集和非聚集 SQL 索引来优化 SQL 查询，非聚集索引单独存储，需要更多的磁盘空间，因此，了解何时使用索引很重要。
该OLAP功能“扩展了SQL解析函数的语法。” SQL 中的 OLAP 功能更快且易于使用，熟悉这些语法的 SQL 开发人员和 DBA 可以很容易地适应和使用它们。
OLAP 函数可以创建所有标准计算度量，例如排名、移动聚合、份额、期初至今、前期和未来期、平行期等。
查询优化器使用统计信息来确定如何最好地连接表、何时应该使用索引以及如何访问这些索引等，无论是手动还是自动，SQL 服务器统计信息都应该保持最新。
过时的 SQL Server 统计信息会影响表、索引或列统计信息，并导致查询计划性能不佳。
SQL 查询优化可以轻松提高系统性能，从而节省成本，优化 SQL 查询可以提高运营效率并加快性能，从而提高系统上线进度。
SQL 查询优化很重要，原因有很多，包括：
组织可以通过更快的响应时间获得可靠的数据访问和高水平的性能，优化 SQL 查询不仅可以提高整体系统性能，还可以提高组织的声誉，最终，SQL 查询优化的最佳实践帮助用户获得准确、快速的数据库结果。
❼ SQL优化万能公式：5 大步骤 + 10 个案例
在应用开发的早期，数据量少，开发人员开发功能时更重视功能上的实现，随着生产数据的增长，很多SQL语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的SQL就是整个系统性能的瓶颈。
1、通过慢查日志等定位那些执行效率较低的SQL语句
2、explain 分析SQL的执行计划
type由上至下，效率越来越高
Extra
3、show profile 分析
了解SQL执行的线程的状态及消耗的时间。默认是关闭的，开启语句“set profiling = 1;”
4、trace
trace分析优化器如何选择执行计划，通过trace文件能够进一步了解为什么优惠券选择A执行计划而不选择B执行计划。
5、确定问题并采用相应的措施
案例1、最左匹配
索引
SQL语句
查询匹配从左往右匹配，要使用order_no走索引，必须查询条件携带shop_id或者索引( shop_id , order_no )调换前后顺序
案例2、隐式转换
索引
SQL语句
隐式转换相当于在索引上做运算，会让索引失效。mobile是字符类型，使用了数字，应该使用字符串匹配，否则MySQL会用到隐式替换，导致索引失效。
案例3、大分页
索引
SQL语句
对于大分页的场景，可以优先让产品优化需求，如果没有优化的，有如下两种优化方式， 一种是把上一次的最后一条数据，也即上面的c传过来，然后做“c < xxx”处理，但是这种一般需要改接口协议，并不一定可行。另一种是采用延迟关联的方式进行处理，减少SQL回表，但是要记得索引需要完全覆盖才有效果，SQL改动如下
案例4、in + order by
索引
SQL语句
in查询在MySQL底层是通过n*m的方式去搜索，类似union，但是效率比union高。in查询在进行cost代价计算时（代价 = 元组数 * IO平均值），是通过将in包含的数值，一条条去查询获取元组数的，因此这个计算过程会比较的慢，所以MySQL设置了个临界值(eq_range_index_pe_limit)，5.6之后超过这个临界值后该列的cost就不参与计算了。因此会导致执行计划选择不准确。默认是200，即in条件超过了200个数据，会导致in的代价计算存在问题，可能会导致Mysql选择的索引不准确。
处理方式，可以( order_status , created_at )互换前后顺序，并且调整SQL为延迟关联。
案例5、范围查询阻断，后续字段不能走索引
索引
SQL语句
范围查询还有“IN、between”
案例6、不等于、不包含不能用到索引的快速搜索。（可以用到ICP）
在索引上，避免使用NOT、!=、>、!、NOT EXISTS、NOT IN、NOT LIKE等
案例7、优化器选择不使用索引的情况
如果要求访问的数据量很小，则优化器还是会选择辅助索引，但是当访问的数据占整个表中数据的蛮大一部分时（一般是20%左右），优化器会选择通过聚集索引来查找数据。
查询出所有未支付的订单，一般这种订单是很少的，即使建了索引，也没法使用索引。
案例8、复杂查询
如果是统计某些数据，可能改用数仓进行解决；如果是业务上就有那么复杂的查询，可能就不建议继续走SQL了，而是采用其他的方式进行解决，比如使用ES等进行解决。
案例9、asc和desc混用
desc 和asc混用时会导致索引失效
案例10、大数据
对于推送业务的数据存储，可能数据量会很大，如果在方案的选择上，最终选择存储在MySQL上，并且做7天等有效期的保存。那么需要注意，频繁的清理数据，会照成数据碎片，需要联系DBA进行数据碎片处理。