sql优化

前言 　　索引对于MySQL来说，是非常重要的篇章。索引知识点巨多，要想掌握透彻，需要逐个知识点--击破。本文介绍关于什么情况导致索引失效问题。 图片总结 索引失效 全值匹配（索引最佳） 若主键索引和唯一索引都存在，优先主键索引。 没有主键索引 使用唯一索引。 1. 违反最左前缀法则 　　如果索引有多列（复合索引），要遵守最左前缀法则 即查询从索引的最左/前列必须存在，与顺序无关。 如下图，k1列是最左/前列，无论在哪个位置，都会使用到索引查询。 如下图，最左/前列k1不存在，索引失效，忽略了 索引查询 ，启动了 全表扫描 。 2. 不要在索引列上做任何操作 如计算、函数、（自动or手动）类型转换等操作，会导致索引失效从而全表扫描。 如图，下面两个SQL结果集相同。 3. 索引范围条件右边的列 当SQL中出现范围性条件筛选，则在范围条件后面的索引条件失效。 4. 尽量使用覆盖索引 SQL中的查询列和条件中都为索引字段。 5. 不要使用不等于（！=、<>） MySQL在使用不等于（！<>、<>）的时候无法使用索引会导致全表扫描（除覆盖索引外） 如果是覆盖索引 6. like相关SQL ① like通配符 % 出现在 开头 ，会导致索引失效 ② like通配符 % 出现在字符 后面 ，不会导致索引失败 7. 字符串不加单引号索引失效 加单引号 不加单引号 8 or连接 尽量少用or 9

对于一个以数据为中心的应用，数据库的好坏直接影响到程序的性能，因此数据库性能至关重要。一般来说，要保证数据库的效率，要做好以下四个方面的工作：数据库设计、sql语句优化、数据库参数配置、恰当的硬件资源和操作系统，这个顺序也表现了这四个工作对性能影响的大小。下面我们逐个阐明： 一、数据库设计 　　适度的反范式,注意是适度的 　　我们都知道三范式，基于三范式建立的模型是最有效保存数 据的方式，也是最容易扩展的模式。我们在开发应用程序时，设计的数据库要最大程度的遵守三范式，特别是对于OLTP型的系统，三范式是必须遵守的规则。当 然，三范式最大的问题在于查询时通常需要join很多表，导致查询效率很低。所以有时候基于性能考虑，我们需要有意的违反三范式，适度的做冗余，以达到提 高查询效率的目的。注意这里的反范式是适度的，必须为这种做法提供充分的理由。下面就是一个糟糕的实例：　　 　 　在这里，为了提高学生活动记录的检索效率，把单位名称冗余到学生活动记录表里。单位信息有500条记录，而学生活动记录在一年内大概有200万数据量。 如果学生活动记录表不冗余这个单位名称字段，只包含三个int字段和一个timestamp字段，只占用了16字节，是一个很小的表。而冗余了一个 varchar(32)的字段后则是原来的3倍，检索起来相应也多了这么多的I/O。而且记录数相差悬殊，500 VS 2000000

当 MySQL 单表记录数过大时，增删改查性能都会急剧下降，可以参考以下步骤来优化： 单表优化 除非单表数据未来会一直不断上涨，否则不要一开始就考虑拆分，拆分会带来逻辑、部署、运维的各种复杂度，一般以整型值为主的表在千万级以下，字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间，甚至能正常支撑千万级以上的数据量： 字段 尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT，如果非负则加上UNSIGNED VARCHAR的长度只分配真正需要的空间 使用枚举或整数代替字符串类型 尽量使用TIMESTAMP而非DATETIME， 单表不要有太多字段，建议在20以内 避免使用NULL字段，很难查询优化且占用额外索引空间 用整型来存IP 索引 索引并不是越多越好，要根据查询有针对性的创建，考虑在WHERE和ORDER BY命令上涉及的列建立索引，可根据EXPLAIN来查看是否用了索引还是全表扫描 应尽量避免在WHERE子句中对字段进行NULL值判断，否则将导致引擎放弃使用索引而进行全表扫描 值分布很稀少的字段不适合建索引，例如"性别"这种只有两三个值的字段 字符字段只建前缀索引 字符字段最好不要做主键 不用外键，由程序保证约束 尽量不用UNIQUE，由程序保证约束 使用多列索引时主意顺序和查询条件保持一致

一、何为数据库 数据库是“按照数据结构来组织、存储和管理数据的仓库”。是一个长期存储在计算机内的、有组织的、有共享的、统一管理的数据集合。 数据库是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合，可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。 二、数据库的作用 ⑴ 实现数据共享 数据共享包含所有用户可同时存取数据库中的数据，也包括用户可以用各种方式通过接口使用数据库，并提供数据共享。 ⑵ 减少数据的冗余度 同文件系统相比，由于数据库实现了数据共享，从而避免了用户各自建立应用文件。减少了大量重复数据，减少了数据冗余，维护了数据的一致性。 ⑶ 数据的独立性 数据的独立性包括逻辑独立性（数据库中数据库的逻辑结构和应用程序相互独立）和物理独立性（数据物理结构的变化不影响数据的逻辑结构）。 ⑷ 数据实现集中控制 文件管理方式中，数据处于一种分散的状态，不同的用户或同一用户在不同处理中其文件之间毫无关系。利用数据库可对数据进行集中控制和管理，并通过数据模型表示各种数据的组织以及数据间的联系。 ⑸数据一致性和可维护性，以确保数据的安全性和可靠性 主要包括：①安全性控制：以防止数据丢失、错误更新和越权使用；②完整性控制：保证数据的正确性、有效性和相容性；③并发控制：使在同一时间周期内

关于存储过程学习自 ：http://blog.sina.com.cn/s/blog_52d20fbf0100ofd5.html mysql存储过程详解 1. 存储过程简介 我们常用的操作数据库语言 SQL 语句在执行的时候需要要先编译，然后执行，而 存储过程（ Stored Procedure ）是一组为了完成特定功能的 SQL 语句集，经编译后存储在数据库中，用户通过指定存储过程的名字并给定参数（如果该存储过程带有参数）来调用执行它 。 一个存储过程是一个可编程的函数，它在数据库中创建并保存。它可以有 SQL 语句和一些特殊的控制结构组成。当希望在不同的应用程序或平台上执行相同的函数，或者封装特定功能时，存储过程是非常有用的。数据库中的存储过程可以看做是对编程中面向对象方法的模拟。它允许控制数据的访问方式。 存储过程通常有以下优点： (1). 存储过程增强了 SQL 语言的功能和灵活性。存储过程可以用流控制语句编写，有很强的灵活性，可以完成复杂的判断和较复杂的运算。 (2). 存储过程允许标准组件是编程。存储过程被创建后，可以在程序中被多次调用，而不必重新编写该存储过程的 SQL 语句。而且数据库专业人员可以随时对存储过程进行修改，对应用程序源代码毫无影响。 (3). 存储过程能实现较快的执行速度。如果某一操作包含大量的 Transaction-SQL 代码或分别被多次执行

改善SQL语句 很多人不知道SQL语句在SQL SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。比如： select * from table1 where name='zhangsan' and tID > 10000 和执行: select * from table1 where tID > 10000 and name='zhangsan' 一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的10000条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个name='zhangsan'的，而后再根据限制条件条件tID>10000来提出查询结果。 事实上，这样的担心是不必要的。SQL SERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。 虽然查询优化器可以根据where子句自动的进行查询优化，但大家仍然有必要了解一下“查询优化器”的工作原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。 在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的

原文 我们经常使用MYSQL的执行计划来查看SQL语句的执行效率，接下来分析下执行计划各个显示的内容。 EXPLAIN SELECT * FROM users WHERE id IN (SELECT userID FROMuser_address WHERE address = "湖南长沙麓谷") ; 学习目标：看过这篇文章后会简要分析sql执行的性能，建立合理的索引 执行计划的id select查询的序列号，标识执行的顺序： 1.id相同，执行顺序由上至下； 2.id不同，如果是子查询，id号会递增，id值越大优先级越高，越先被执行 执行计划的select_type 查询的类型，主要用于区分普通查询、联合查询、子查询等： 1.SIMPLE：简单的select查询，查询中不包含子查询或者union 2.PRIMARY：查询总包含子查询，最外层则被标记为primary 3.SUBQUERY/MATERIALIZED：SUBQUERY表示在select或where列表中包含了子查询，MATERIALIZED表示where后边in条件的子查询 4.UNION：表示union中的第二个或者后面的select语句 5.UNION RESULT：union的结果 对于 UNION 和 UNION RESULT 可以通过下面的例子展现： EXPLAIN SELECT * FROM users

对于缓存，一般人想到的是 redis、memcache 这些内存型的缓存。 但是实际上 mysql 也提供了缓存，mysql 里面的缓存是查询缓存，可以把我们查询过的语句缓存下来，下一次查询的时候有可能就直接从缓存返回（缓存命中）。 当然使用 mysql 缓存也不是没有坏处，mysql 多了个管理缓存的任务，需要写入缓存，然后如果判断里面的缓存已经过期，又要从里面删除缓存。 查看查询缓存情况： mysql> show variables like '%query_cache%'; （query_cache_type 为 ON 表示已经开启） +------------------------------+----------+ | Variable_name | Value | +------------------------------+----------+ | have_query_cache | YES | | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 20971520 | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | +-------------------

索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它们包含着对数据表里所有记录的引用指针。 注： [1] 索引不是万能的 ！ 索引可以加快数据检索操作，但会使数据修改操作变慢。每修改数据记录，索引就必须刷新一次。为了在某种程序上弥补这一缺陷，许多SQL命令都有一个DELAY_KEY_WRITE项。这个选项的作用是暂时制止MySQL在该命令每插入一条新记录和每修改一条现有之后立刻对索引进行刷新，对索引的刷新将等到全部记录插入/修改完毕之后再进行。在需要把许多新记录插入某个数据表的场合，DELAY_KEY_WRITE选项的作用将非常明显。 [2]另外， 索引还会在硬盘上占用相当大的空间 。 因此应该只为最经常查询和最经常排序的数据列建立索引。注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。 从理论上讲，完全可以为数据表里的每个字段分别建一个索引，但MySQL把同一个数据表里的索引总数限制为16个。 1. InnoDB数据表的索引 与MyISAM数据表相比，索引对InnoDB数据的重要性要大得多。在InnoDB数据表上，索引对InnoDB数据表的重要性要在得多。在 InnoDB数据表上，索引不仅会在搜索数据记录时发挥作用，还是数据行级锁定机制的苊、基础。”数据行级锁定”的意思是指在事务操作的执行过程中锁定正在被处理的个别记录

对于一个以数据为中心的应用，数据库的好坏直接影响到程序的性能，因此数据库性能至关重要。一般来说，要保证数据库的效率，要做好以下四个方面的工作：数 据库设计、sql语句优化、数据库参数配置、恰当的硬件资源和操作系统，这个顺序也表现了这四个工作对性能影响的大小。下面我们逐个阐明： 一、数据库设计 　　适度的反范式,注意是适度的 　　我们都知道三范式，基于三范式建立的模型是最有效保存数 据的方式，也是最容易扩展的模式。我们在开发应用程序时，设计的数据库要最大程度的遵守三范式，特别是对于OLTP型的系统，三范式是必须遵守的规则。当 然，三范式最大的问题在于查询时通常需要join很多表，导致查询效率很低。所以有时候基于性能考虑，我们需要有意的违反三范式，适度的做冗余，以达到提 高查询效率的目的。注意这里的反范式是适度的，必须为这种做法提供充分的理由。下面就是一个糟糕的实例：　　 　 　在这里，为了提高学生活动记录的检索效率，把单位名称冗余到学生活动记录表里。单位信息有500条记录，而学生活动记录在一年内大概有200万数据量。 如果学生活动记录表不冗余这个单位名称字段，只包含三个int字段和一个timestamp字段，只占用了16字节，是一个很小的表。而冗余了一个 varchar(32)的字段后则是原来的3倍，检索起来相应也多了这么多的I/O。而且记录数相差悬殊，500 VS 2000000