sql优化

聚集索引 , 表中存储的数据按照索引的顺序存储,检索效率比普通索引高,但对数据新增/修改/删除的影响比较大 非聚集索引 ,不影响表中的数据存储顺序,检索效率比聚集索引低,对数据新增/修改/删除的影响很小 如何让你的SQL运行得更快 ---- 人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略 了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库 环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。笔者在工作实践 中发现，不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的whe re子句。在对它们进行适当的优化后，其运行速度有了明显地提高！下面我将从这三个 方面分别进行总结： ---- 为了更直观地说明问题，所有实例中的SQL运行时间均经过测试，不超过１秒的均 表示为（< 1秒）。 ---- 测试环境-- ---- 主机：HP LH II ---- 主频：330MHZ ---- 内存：128兆 ---- 操作系统：Operserver5.0.4 ----数据库：Sybase11.0.3 一、不合理的索引设计 ----例：表record有620000行，试看在不同的索引下，下面几个 SQL的运行情况： ---- 1.在date上建有一非个群集索引 select count(*) from record

sql Server 索引优化 聚集索引 , 表中存储的数据按照索引的顺序存储 , 检索效率比普通索引高 , 但对数据新增 / 修改 / 删除的影响比较大 非聚集索引 , 不影响表中的数据存储顺序 , 检索效率比聚集索引低 , 对数据新增 / 修改 / 删除的影响很小 如何让你的 SQL 运行得更快 ---- 人们在使用 SQL 时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略 了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库 环境中（如联机事务处理 OLTP 或决策支持系统 DSS ）中表现得尤为明显。笔者在工作实践 中发现，不良的 SQL 往往来自于不恰当的索引设计、不充份的连接条件和不可优化的 whe re 子句。在对它们进行适当的优化后，其运行速度有了明显地提高！下面我将从这三个 方面分别进行总结： ---- 为了更直观地说明问题，所有实例中的 SQL 运行时间均经过测试，不超过１秒的均 表示为（ < 1 秒）。 ---- 测试环境 -- ---- 主机： HP LH II ---- 主频： 330MHZ ---- 内存： 128 兆 ---- 操作系统： Operserver5.0.4 ---- 数据库： Sybase11.0.3 一、不合理的索引设计 ---- 例：表 record 有 620000 行，试看在不同的索引下，下面几个

查询实际执行计划,看走的是那种查询 要根据需求,建立合适的索引 经常需要汇总的,可以建立包含索引 --drop index ix_smssend_created on smssent_1 ; create index ix_smssend_created on smssent_1 (created) include(status,co_id,shop_id,channel_id,sms_type,sms_qty) 来源： https://www.cnblogs.com/xinzhyu/p/11056369.html

一、前言 作为程序员的你，数据库作为一门必修课，而MySQL数据库毫无疑问已经是最常用的数据库了。系统的稳定、高效、高并发等指标，很大程度上取决于数据库性能是否够优，可见性能优化的重要性，这也就不难理解各位在任何一场面试中都会被问及到数据库调优相关的问题。 因此，这就是我为何考虑写该系列文章的主要原因，希望该系列文章( MySQL性能优化 )能够给你带来收获，让你更系统、更全面的掌握MySQL性能优化的技能、技巧。该系列文章将会持续分享、更新，如果觉得现在或者将来可能对你有用，不妨持续关注、收藏。 在MySQL性能优化之前，你有必要重新再认识下MySQL，便于后续更容易理解MySQL性能优化中涉及到的知识点。本文将从MySQL架构、核心问题来针对性展开讨论，这也将是 MySQL性能优化 系列文章的开篇之作。 二、MySQL逻辑架构 想深入探究MySQL之前，有必要了解一下MySQL的逻辑架构，逻辑架构图如下： MySQL的逻辑架构中，分为三层，如上图红色虚线框的三部分。 最上层架构并不是MySQL所独有的，大多数基于客户端/服务器形态的系统或者服务，都有类似的架构，其中包含MySQL的连接处理、授权认证、安全控制等等。 第二层架构是MySQL中最为核心的部分，其中包括查询解析、分析、优化、缓存以及所有的内置函数(如：日期、时间、函数等)，所有跨存储引擎的功能都在这一层实现，例如

http://blog.csdn.net/alongken2005/article/details/6394016 Analyze Table MySQL 的Optimizer（优化元件）在优化SQL语句时，首先需要收集一些相关信息，其中就包括表的cardinality（可以翻译为“散列程度”），它表示某个索引对应的列包含多少个不同的值——如果cardinality大大少于数据的实际散列程度，那么索引就基本失效了。 我们可以使用SHOW INDEX语句来查看索引的散列程度： SHOW INDEX FROM PLAYERS; TABLE KEY_NAME COLUMN_NAME CARDINALITY ------- -------- ----------- ----------- PLAYERS PRIMARY PLAYERNO 14 因为此时PLAYER表中不同的PLAYERNO数量远远多于14，索引基本失效。 下面我们通过Analyze Table语句来修复索引： ANALYZE TABLE PLAYERS; SHOW INDEX FROM PLAYERS; 结果是： TABLE KEY_NAME COLUMN_NAME CARDINALITY ------- -------- ----------- ----------- PLAYERS PRIMARY PLAYERNO

1、 用程序中，保证在实现功能的基础上，尽量减少对数据库的访问次数；通过搜索参数，尽量减少对表的访问行数,最小化结果集，从而减轻 网络 负担；能够分开的操作尽量分开处理，提高每次的响应速度；在数据窗口使用SQL时，尽量把使用的索引放在选择的首列； 　　算法的结构尽量简单；在查询时，不要过多地使用通配符如SELECT * FROM T1语句，要用到几列就选择几列如：SELECT COL1,COL2 FROM T1；在可能的情况下尽量限制尽量结果集行数如：SELECT TOP 300 COL1,COL2,COL3 FROM T1,因为某些情况下用户是不需要那么多的数据的。不要在应用中使用数据库游标，游标是非常有用的工具，但比使用常规的、面向集的SQL语句需要更大的开销；按照特定顺序提取数据的查找。 　　2、 避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如: SELECT name FROM employee WHERE salary ＞ 60000 　　在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。 　　3、

MySQL中的查询语句执行分析 select * from T where id =1; 基本架构 示意图 客户端 连接器 查询缓存 分析器 优化器 执行器 存储引擎 存储引擎 存储引擎 MySQL大致可以分为Server层和存储引擎层 Server层包括：连接器、查询缓存、分析器、优化器、执行器等，Server层是通用的，可以配合不同的存储引擎使用。 存储引擎层负责数据的存储和提取，其支持：InnoDB(默认的存储引擎)、MyISAM、Memory等多个存储引擎。 连接器 负责客户端和服务端的连接，验证用户名和密码，获取拥有的权限信息，如果在获取连接之后做出权限变更，对于未关闭的连接，是感知不到权限的变化的。 连接关闭时间由参数 wait_timeout 控制，默认值是8小时。 连接分为短连接和长连接，区别在于，长连接存活时间比较长，可以供更多的查询使用，而短连接经过几次查询就会断开了，下次查询需要重新获取连接。 由于建立连接的过程比较耗时，建议使用长连接，但是过多的使用长连接会导致内存占用会变大。两个解决问题的办法： 定期断开长连接释放内存资源. 执行mysql_reset_connection来重新初始化连接资源，使其恢复到刚刚创建完连接的状态，且不需要重新连接和权限验证等。 查询缓存 MySQL在拿到一个查询语句后，首先会查询缓存中是否存在之前执行过的同样的sql

为SQL视图建立索引 [ 引用 ] CREATE INDEX 语句的要求 在视图上创建的第一个索引必须是唯一聚集索引。在创建唯一聚集索引后，可创建其它非聚集索引。视图上的索引命名规则与表上的索引命名规则相同。唯一区别是表名由视图名替换。有关更多信息，请参见 CREATE INDEX 。 除了一般的 CREATE INDEX 要求外， CREATE INDEX 语句还必须满足下列要求： 执行 CREATE INDEX 语句的用户必须是视图的所有者。 当执行 CREATE INDEX 语句时，下列 SET 选项必须设置为 ON ： ANSI_NULLS ANSI_PADDING ANSI_WARNINGS ARITHABORT CONCAT_NULL_YIELDS_NULL QUOTED_IDENTIFIERS 必须将选项 NUMERIC_ROUNDABORT 选项设置为 OFF 。 视图不能包含 text 、 ntext 或 image 列，即使在 CREATE INDEX 语句中没有引用它们。 如果视图定义中的 SELECT 语句指定了一个 GROUP BY 子句，则唯一聚集索引的键只能引用在 GROUP BY 子句中指定的列。 -- --------------------------------------------------------------------------

MySQL数据库技术的方方面面也是很多，这里只涉及必备的性能调优，推崇从下向上的性能调优，主要包括运行环境，配置参数，SQL性能，和系统架构设计调优。 运行环境调优 这里是Linux的天下，MySQL 运行环境的调优往往和Linux的内核调优一并完成。当然了，对云服务RDS 也有一定的参考作用。 调整Linux默认的IO调度算法 IO调度器的总体目标是希望让磁头能够总是往一个方向移动,移动到底了再往反方向走,这恰恰就是现实生活中的电梯模型,所以IO调度器也被叫做电梯 (elevator)，而相应的算法也就被叫做电梯算法.而Linux中IO调度的电梯算法有好几种,一个叫做as(Anticipatory),一个叫做 cfq(Complete Fairness Queueing),一个叫做deadline,还有一个叫做noop(No Operation). IO对数据库的影响较大，linux默认的IO调度算法为cfq,需要修改为deadline,如果是SSD或者PCIe-SSD设备,需要修改为noop,可以使用下面两种修改方式。 1、在线动态修改,重启失效。 echo “deadline” > /sys/block/sda/queue/scheduler 2、修改/etc/grub.conf,永久生效。 修改/etc/grub.conf配置文件,在kernel那行增加一个配置,例如:

Mysql 在5.6.3中，优化器更有效率地处理派生表（ 在from语句中的子查询 ）： 优化器推迟物化子查询在from语句中的子查询，知道子查询的内容在查询正真执行需要时，才开始物化。这一举措提高了性能： 1：之前版本（5.6.3），from语句中的子查询在 explain select 查看执行计划语句执行时就会物化。它导致了部分查询执行，但explain语句的目的是获取执行计划信息，而不是执行查询 该版本物化不会在explain中发生，所以explain执行计划结果的得到更快； 2：因为上面提及的，物化子查询的推迟有可能不会发生。考虑一个from语句中的子查询的结果和另一个表join(链接)查询，如果优化器先处理另一张表A，然后发现A中没有满足条件的行返回，此时join不会再继续执行，并且优化器会完全跳过物化子查询这步骤； 考虑下面的explain语句，子查询出现在form语句中； EXPLAIN SELECT * FROM (SELECT * FROM t1) AS derived_t1; 优化器避免物化子查询直到子查询的结果在查询真正执行需要时。在上面情况下，查询并没有执行，所有并没有物化（子查询）； 即使查询执行时，也会要求优化器去避免物化。考虑下面的查询： SELECT * FROM t1 JOIN (SELECT t2.f1 FROM t2) AS derived