sql优化

索引使用建议： a,经常检索的列 b,经常用于表连接的列 c,经常排序/分组的列 索引不使用建议： a,基数很低的列 b,经常用于表连接的列 c,经常排序/分组的列 innodb主键特点： a,索引定义时，若不显示包含主键，会隐式加入主键值； b,索引定义时，若显示包含主键，会加入主键值； c,在5.6.9后，优化器已经能自动识别索引末尾的主键值（index extensions）,在这之前则需要显式加上主键列才可以被识别； d,修改主键必然重新拷贝整张表 主键的选择建议： a,对业务透明无意义，免收业务变化的影响； b,主键要很少修改和删除；（删除还好，影响不大，innodb小范围做数据页合并） c,主键最好是自增的； d,不要具有动态属性，例如最后修改时间戳；（如果经常变化会导致聚集索引的值发生变化，相应的导致btree索引值旋转、分裂、位移） innodb聚集索引选择顺序原则： a,显示声明的主键； b,第一个不包含null值的唯一索引列； c,内置的rowid（自增逻辑值，6byte且不可引用） innodb聚集索引不建议选用频繁更新、随机写入（离散IO） 唯一索引（unique key） a,不允许具有索引值相同的行，从而禁止重复的索引或键值； b,在唯一约束上，和主键一样（以myisam引擎为代表）； c,和主键区别：1，唯一索引允许有空值（null） 2

监控 SQL Server (2005/2008) 的运行状况--来自微软TetchNet 原文地址： http://technet.microsoft.com/zh-cn/library/bb838723.aspx Microsoft SQL Server 2005 提供了一些工具来监控数据库。方法之一是动态管理视图。动态管理视图 (DMV) 和动态管理函数 (DMF) 返回的服务器状态信息可用于监控服务器实例的运行状况、诊断问题和优化性能。 常规服务器动态管理对象包括： dm_db_*：数据库和数据库对象 dm_exec_*：执行用户代码和关联的连接 dm_os_*：内存、锁定和时间安排 dm_tran_*：事务和隔离 dm_io_*：网络和磁盘的输入/输出 此部分介绍为监控 SQL Server 运行状况而针对这些动态管理视图和函数运行的一些常用查询。 摘录部分精彩SQL如下： 下面的查询显示 CPU 平均占用率最高的前 50 个 SQL 语句。 SELECT TOP 50 total_worker_time / execution_count AS [ Avg CPU Time ] , ( SELECT SUBSTRING ( text ,statement_start_offset / 2 ,( CASE WHEN statement_end_offset = - 1

引言 近期由于复习了一下mysql的内容，有些心得。随手讲其中一部分知识，都是一些烟哥自己平时工作的总结以及经验。大家看完，其实能避开很多坑。而且很多问题，都是面试中实打实会问到的！ 比如 OK，具体有下面这些问题 1、为什么一定要设一个主键？ 2、你们主键是用自增还是UUID? 3、主键为什么不推荐有业务含义? 4、表示枚举的字段为什么不用enum类型？ 5、货币字段用什么类型? 6、时间字段用什么类型? 7、为什么不直接存储图片、音频、视频等大容量内容? 8、字段为什么要定义为NOT NULL? 其实上面这些问题，我最早想法是，每个问题都可以啰嗦出一篇文章。后来由于良心发现，烟哥就决定用一篇文章将这些问题都讲明白。 当然，我给的回答可能并非标准答案，毕竟是自己的一些工作总结。各位读者有更好的回答，也欢迎交流！ 这里我要说一下，我用mysql只用过 innodb 存储引擎，其他的引擎真没用过。因此我的回答，都是基于 innodb 存储引擎中的。 正文 问题1:为什么一定要设一个主键？ 回答 :因为你不设主键的情况下，innodb也会帮你生成一个隐藏列，作为自增主键。所以啦，反正都要生成一个主键，那你还不如自己指定一个主键，在有些情况下，就能显式的用上主键索引，提高查询效率！ 问题2:主键是用自增还是UUID? 回答 :肯定答自增啊。innodb 中的主键是聚簇索引

MySQL经典面试题 1、MySQL的复制原理以及流程 (1)、复制基本原理流程 1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中； 2. 从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进 自己的relay log中； 3. 从：sql执行线程——执行relay log中的语句； (2)、MySQL复制的线程有几个及之间的关联 MySQL 的复制是基于如下 3 个线程的交互（ 多线程复制里面应该是 4 类线程）： 1. Master 上面的 binlog dump 线程，该线程负责将 master 的 binlog event 传到slave； 2. Slave 上面的 IO 线程，该线程负责接收 Master 传过来的 binlog，并写入 relay log； 3. Slave 上面的 SQL 线程，该线程负责读取 relay log 并执行； 4. 如果是多线程复制，无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制， SQL 线程只做 coordinator，只负责把 relay log 中的 binlog读出来然后交给 worker 线程， woker 线程负责具体 binlog event 的执行； (3)

MySQL经典面试题 1、MySQL的复制原理以及流程 (1)、复制基本原理流程 1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中； 2. 从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进 自己的relay log中； 3. 从：sql执行线程——执行relay log中的语句； (2)、MySQL复制的线程有几个及之间的关联 MySQL 的复制是基于如下 3 个线程的交互（ 多线程复制里面应该是 4 类线程）： 1. Master 上面的 binlog dump 线程，该线程负责将 master 的 binlog event 传到slave； 2. Slave 上面的 IO 线程，该线程负责接收 Master 传过来的 binlog，并写入 relay log； 3. Slave 上面的 SQL 线程，该线程负责读取 relay log 并执行； 4. 如果是多线程复制，无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制， SQL 线程只做 coordinator，只负责把 relay log 中的 binlog读出来然后交给 worker 线程， woker 线程负责具体 binlog event 的执行； (3)

一、什么是JDBC 1、概念 JDBC由一组用Java语言编写的类和接口组成，是Java和数据库之间的一个桥梁，是一个规范，而不是一个实现，能够执行SQL语句。 2、各种不同类型的数据库都有相应的实现 所有不同类型数据库的开发商依照这这种规范编写了相应Java代码以提供相应的操作数据库的方法。 3、关于数据库的执行流程 二、用JDBC访问MySQL 1、配置 （1）导入相关依赖 < ! -- https : / / mvnrepository . com / artifact / mysql / mysql - connector - java -- > < dependency > < groupId > mysql < / groupId > < artifactId > mysql - connector - java < / artifactId > < version > 5.1 .31 < / version > < / dependency > （2）参数配置 pro = new Properties ( ) ; try { //参数配置 pro . load ( new FileInputStream ( "D:\\db.properties" ) ) ; jdbcDriver = pro . getProperty ( "jdbcDriver" ) ;

MySQL经典面试题 1、MySQL的复制原理以及流程 (1)、复制基本原理流程 1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中； 2. 从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进 自己的relay log中； 3. 从：sql执行线程——执行relay log中的语句； (2)、MySQL复制的线程有几个及之间的关联 MySQL 的复制是基于如下 3 个线程的交互（ 多线程复制里面应该是 4 类线程）： 1. Master 上面的 binlog dump 线程，该线程负责将 master 的 binlog event 传到slave； 2. Slave 上面的 IO 线程，该线程负责接收 Master 传过来的 binlog，并写入 relay log； 3. Slave 上面的 SQL 线程，该线程负责读取 relay log 并执行； 4. 如果是多线程复制，无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制， SQL 线程只做 coordinator，只负责把 relay log 中的 binlog读出来然后交给 worker 线程， woker 线程负责具体 binlog event 的执行； (3)

1)、复制基本原理流程 1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中； 2. 从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进 自己的relay log中； 3. 从：sql执行线程——执行relay log中的语句； (2)、MySQL复制的线程有几个及之间的关联 MySQL 的复制是基于如下 3 个线程的交互（ 多线程复制里面应该是 4 类线程）： 1. Master 上面的 binlog dump 线程，该线程负责将 master 的 binlog event 传到slave； 2. Slave 上面的 IO 线程，该线程负责接收 Master 传过来的 binlog，并写入 relay log； 3. Slave 上面的 SQL 线程，该线程负责读取 relay log 并执行； 4. 如果是多线程复制，无论是 5.6 库级别的假多线程还是 MariaDB 或者 5.7 的真正的多线程复制， SQL 线程只做 coordinator，只负责把 relay log 中的 binlog读出来然后交给 worker 线程， woker 线程负责具体 binlog event 的执行； (3)、MySQL如何保证复制过程中数据一致性及减少数据同步延时 一致性主要有以下几个方面

一.什么导致查询速度变慢 在尝试编写快速的查询之前,需要清除一点,真正重要是响应时间。如果把查询看作是一个任务，那么他由一系列子任务组成，每个子任务都会消耗一定的时间。如果要优化查询，实际上要优化其子任务，要么消除其中一些子任务，要么减少子任务的执行的次数，要么让子任务运行得更快。 　　MySQL在执行查询的时候有哪些子任务。哪些子任务运行的速度很慢,这里很难给出完整的列表，通常来说查询的生命周期大致可以按照顺序来看：从客户端，到服务器，然后再服务器上进行解析，生成执行计划，执行，并返回结果给客户端。其中“执行”可以认为是整个生命周期中最重要的阶段，这其中包括了大量为了检索数据到存储引擎的调用以及调用后的数据处理，包括排序、分组等。　　 　　在完成这些人物的时候，查询需要在不同的地方花费时间，包括网络，CPU计算，生成统计信息和执行计划、锁等待（互斥等待）等操作，尤其是向底层存储引擎检索数据的调用擦欧总，这些调用需要在内存操作、CPU操作和内存不足时导致的I/O操作上消耗时间，根据引擎不同，可能还会产生大量的上下文切换以及系统调用。 　　在每一个消耗大量时间的查询案例中，我们都能看到一些不必要的额外操作、某些操作被额外地重复了很多次、某些操作执行得太慢等。优化查询的目的就是减少和消除这些操作所花费的时间。 二.优化数据库访问 最简单衡量查询开销的三个指标 响应时间

索引 索引是为了提高数据查询的效率，就类似与书的目录。 索引的常见模型 哈希表 ，也就是KV类型的结构，输入K即可得到相应的值，思路就是把值放到数组里，用一个哈希函数把K换成一个位置，然后在这个位置上找寻value。当不同的K经过换算有相同的结果是，采用拉链法。如下图： 在这个图中，倘若K换算后的值得到的N，那么目标就是N位置后面的链表的某一个。采用顺序查找。用哈希表查询等值很快，但是缺点是不能进行范围查询。 有序数组 ，相比于哈希表，有序数组的好处就是可以进行范围查询，同时，用二分的话，等值查询的性能也可以很好的保证。但是，有序数组的缺点就是只适合静态存储引擎。 二叉搜索树 ，根据二叉树的特点（左孩子小于父节点，右孩子大于父节点），可以很容易来搜索树中的某个值，但是二叉搜索树在一些情况下会出现左右高度不平衡，所以需要保持一颗二叉平衡树，这样查询的复杂度是O(logN)，更新一个结点也是O(logN)。 但是实际上二叉树是很少使用的，原因无他，结点数量过多的情况下，二叉树的高度也增加，访问磁盘的次数也会增加，从而查询变慢，所以引入了N叉树，N的值取决于数据块点大小。 InnoDB的索引模型 InnoDB中，表都是根据主键顺序以索引的形式来存放的，使用B+树来存储。 每一个索引都对应有一个B+树，比如建立一个表并设置一个索引， CREATE table t6( id int