❶ 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、一次更新多条记录比分多次更新每次一条快,就是说批处理好
❷ 磁盘读写和数据库读写哪个效率更高
假定在程序效率和关键过程相当且不计入缓存等措施的条件下，读写任何类型的数据都没有直接操作文件来的快，不论MSYQL过程如何，最后都要到磁盘上去读这个“文件”（记录存储区等效），所以当然这一切的前提是只读 内容，无关任何排序或查找操作。
动态网站一般都是用数据库来存储信息，如果信息的及时性要求不高 可以加入缓存来减少频繁读写数据库。
两种方式一般都支持，但是绕过操作系统直接操作磁盘的性能较高，而且安全性也较高，数据库系中的磁盘性能一直都是瓶颈，大型数据库一般基于unix
系统，当然win下也有，不常用应为win的不可靠性，unix下，用的是裸设备raw设备，就是没有加工过的设备（unix下的磁盘分区属于特殊设备，
以文件形式统一管理），由dbms直接管理，不通过操作系统，效率很高，可靠性也高，因为磁盘，cache和内存都是自己管理的，大型数据库系统
db2，oracal，informix（不太流行了），mssql算不上大型数据库系统。
1、直接读文件相比数据库查询效率更胜一筹，而且文中还没算上连接和断开的时间。
2、一次读取的内容越大，直接读文件的优势会越明
显（读文件时间都是小幅增长，这跟文件存储的连续性和簇大小等有关系），这个结果恰恰跟书生预料的相反，说明MYSQL对更大文件读取可能又附加了某些操
作（两次时间增长了近30%），如果只是单纯的赋值转换应该是差异偏小才对。
3、写文件和INSERT几乎不用测试就可以推测出，数据库效率只会更差。
4、很小的配置文件如果不需要使用到数据库特性，更加适合放到独立文件里存取，无需单独创建数据表或记录，很大的文件比如图片、音乐等采用文件存储更为方便，只把路径或缩略图等索引信息放到数据库里更合理一些。
5、PHP上如果只是读文件，file_get_contents比fopen、fclose更有效率，不包括判断存在这个函数时间会少3秒左右。
6、fetch_row和fetch_object应该是从fetch_array转换而来的，书生没看过PHP的源码，单从执行上就可以说明fetch_array效率更高，这跟网上的说法似乎相反。
磁盘读写与数据库的关系：
一 磁盘物理结构
(1) 盘片：硬盘的盘体由多个盘片叠在一起构成。
在硬盘出厂时，由硬盘生产商完成了低级格式化(物理格式化)，作用是将空白的盘片(Platter)划分为一个个同圆心、不同半径的磁道
(Track)，还将磁道划分为若干个扇区(Sector)，每个扇区可存储128×2的N次方（N=0.1.2.3）字节信息，默认每个扇区的大小为
512字节。通常使用者无需再进行低级格式化操作。
(2) 磁头：每张盘片的正反两面各有一个磁头。
(3) 主轴：所有磁片都由主轴电机带动旋转。
(4) 控制集成电路板：复杂！上面还有ROM（内有软件系统）、Cache等。
二 磁盘如何完成单次IO操作
(1) 寻道
当控制器对磁盘发出一个IO操作命令的时候，磁盘的驱动臂(Actuator
Arm)带动磁头(Head)离开着陆区(Landing
Zone，位于内圈没有数据的区域)，移动到要操作的初始数据块所在的磁道(Track)的正上方，这个过程被称为寻道(Seeking)，对应消耗的时
间被称为寻道时间(Seek Time)；
(2) 旋转延迟
找到对应磁道还不能马上读取数据，这时候磁头要等到磁盘盘片(Platter)旋转到初始数据块所在的扇区(Sector)落在读写磁头正下方之后才能开始读取数据，在这个等待盘片旋转到可操作扇区的过程中消耗的时间称为旋转延时(Rotational Delay)；
(3) 数据传送
接下来就随着盘片的旋转，磁头不断的读/写相应的数据块，直到完成这次IO所需要操作的全部数据，这个过程称为数据传送(Data Transfer)，对应的时间称为传送时间(Transfer Time)。完成这三个步骤之后单次IO操作也就完成了。
根据磁盘单次IO操作的过程，可以发现：
单次IO时间 = 寻道时间 + 旋转延迟 + 传送时间
进而推算IOPS(IO per second)的公式为：
IOPS = 1000ms/单次IO时间
三 磁盘IOPS计算
不同磁盘，它的寻道时间，旋转延迟，数据传送所需的时间各是多少？
1. 寻道时间
考虑到被读写的数据可能在磁盘的任意一个磁道，既有可能在磁盘的最内圈（寻道时间最短），也可能在磁盘的最外圈（寻道时间最长），所以在计算中我们只考虑平均寻道时间。
在购买磁盘时，该参数都有标明，目前的SATA/SAS磁盘，按转速不同，寻道时间不同，不过通常都在10ms以下：
3. 传送时间2. 旋转延时
和寻道一样，当磁头定位到磁道之后有可能正好在要读写扇区之上，这时候是不需要额外的延时就可以立刻读写到数据，但是最坏的情况确实要磁盘旋转整整
一圈之后磁头才能读取到数据，所以这里也考虑的是平均旋转延时，对于15000rpm的磁盘就是(60s/15000)*(1/2) = 2ms。
(1) 磁盘传输速率
磁盘传输速率分两种：内部传输速率(Internal Transfer Rate)，外部传输速率(External Transfer Rate)。
内部传输速率(Internal Transfer Rate)，是指磁头与硬盘缓存之间的数据传输速率，简单的说就是硬盘磁头将数据从盘片上读取出来，然后存储在缓存内的速度。
理想的内部传输速率不存在寻道，旋转延时，就一直在同一个磁道上读数据并传到缓存，显然这是不可能的，因为单个磁道的存储空间是有限的；
实际的内部传输速率包含了寻道和旋转延时，目前家用磁盘，稳定的内部传输速率一般在30MB/s到45MB/s之间(服务器磁盘，应该会更高)。
外部传输速率(External Transfer Rate)，是指硬盘缓存和系统总线之间的数据传输速率，也就是计算机通过硬盘接口从缓存中将数据读出交给相应的硬盘控制器的速率。
硬盘厂商在硬盘参数中，通常也会给出一个最大传输速率，比如现在SATA3.0的6Gbit/s，换算一下就是6*1024/8，768MB/s，通常指的是硬盘接口对外的最大传输速率，当然实际使用中是达不到这个值的。
这里计算IOPS，保守选择实际内部传输速率，以40M/s为例。
(2) 单次IO操作的大小
有了传送速率，还要知道单次IO操作的大小(IO Chunk Size)，才可以算出单次IO的传送时间。那么磁盘单次IO的大小是多少？答案是：不确定。
操作系统为了提高 IO的性能而引入了文件系统缓存(File System Cache)，系统会根据请求数据的情况将多个来自IO的请求先放在缓存里面，然后再一次性的提交给磁盘，也就是说对于数据库发出的多个8K数据块的读操作有可能放在一个磁盘读IO里就处理了。
还有，有些存储系统也是提供了缓存（Cache），接收到操作系统的IO请求之后也是会将多个操作系统的 IO请求合并成一个来处理。
不管是操作系统层面的缓存还是磁盘控制器层面的缓存，目的都只有一个，提高数据读写的效率。因此每次单独的IO操作大小都是不一样的，它主要取决于系统对于数据读写效率的判断。这里以SQL Server数据库的数据页大小为例：8K。
(3) 传送时间
传送时间 = IO Chunk Size/Internal Transfer Rate = 8k/40M/s = 0.2ms
可以发现：
(3.1) 如果IO Chunk Size大的话，传送时间会变大，从而导致IOPS变小；
(3.2) 机械磁盘的主要读写成本，都花在了寻址时间上，即：寻道时间 + 旋转延迟，也就是磁盘臂的摆动，和磁盘的旋转延迟。
(3.3) 如果粗略的计算IOPS，可以忽略传送时间，1000ms/(寻道时间 + 旋转延迟)即可。
4. IOPS计算示例
以15000rpm为例：
(1) 单次IO时间
单次IO时间 = 寻道时间 + 旋转延迟 + 传送时间 = 3ms + 2ms + 0.2 ms = 5.2 ms
(2) IOPS
IOPS = 1000ms/单次IO时间 = 1000ms/5.2ms = 192 (次)
这里计算的是单块磁盘的随机访问IOPS。
考虑一种极端的情况，如果磁盘全部为顺序访问，那么就可以忽略：寻道时间 + 旋转延迟 的时长，IOPS的计算公式就变为：IOPS = 1000ms/传送时间
IOPS = 1000ms/传送时间= 1000ms/0.2ms = 5000 (次)
显然这种极端的情况太过理想，毕竟每个磁道的空间是有限的，寻道时间 + 旋转延迟 时长确实可以减少，不过是无法完全避免的。
四 数据库中的磁盘读写
1. 随机访问和连续访问
(1) 随机访问(Random Access)
指的是本次IO所给出的扇区地址和上次IO给出扇区地址相差比较大，这样的话磁头在两次IO操作之间需要作比较大的移动动作才能重新开始读/写数据。
(2) 连续访问(Sequential Access)
相反的，如果当次IO给出的扇区地址与上次IO结束的扇区地址一致或者是接近的话，那磁头就能很快的开始这次IO操作，这样的多个IO操作称为连续访问。
(3) 以SQL Server数据库为例
数据文件，SQL Server统一区上的对象，是以extent(8*8k)为单位进行空间分配的，数据存放是很随机的，哪个数据页有空间，就写在哪里，除非通过文件组给每个表预分配足够大的、单独使用的文件，否则不能保证数据的连续性，通常为随机访问。
另外哪怕聚集索引表，也只是逻辑上的连续，并不是物理上。
日志文件，由于有VLF的存在，日志的读写理论上为连续访问，但如果日志文件设置为自动增长，且增量不大，VLF就会很多很小，那么就也并不是严格的连续访问了。
2. 顺序IO和并发IO
(1) 顺序IO模式(Queue Mode)
磁盘控制器可能会一次对磁盘组发出一连串的IO命令，如果磁盘组一次只能执行一个IO命令，称为顺序IO；
(2) 并发IO模式(Burst Mode)
当磁盘组能同时执行多个IO命令时，称为并发IO。并发IO只能发生在由多个磁盘组成的磁盘组上，单块磁盘只能一次处理一个IO命令。
(3) 以SQL Server数据库为例
有的时候，尽管磁盘的IOPS(Disk Transfers/sec)还没有太大，但是发现数据库出现IO等待，为什么？通常是因为有了磁盘请求队列，有过多的IO请求堆积。
磁盘的请求队列和繁忙程度，通过以下性能计数器查看：
LogicalDisk/Avg.Disk Queue Length
LogicalDisk/Current Disk Queue Length
LogicalDisk/%Disk Time
这种情况下，可以做的是：
(1) 简化业务逻辑，减少IO请求数；
(2) 同一个实例下，多个数据库迁移的不同实例下；
(3) 同一个数据库的日志，数据文件分离到不同的存储单元；
(4) 借助HA策略，做读写操作的分离。
3. IOPS和吞吐量(throughput)
(1) IOPS
IOPS即每秒进行读写（I/O）操作的次数。在计算传送时间时，有提到，如果IO Chunk Size大的话，那么IOPS会变小，假设以100M为单位读写数据，那么IOPS就会很小。
(2) 吞吐量(throughput)
吞吐量指每秒可以读写的字节数。同样假设以100M为单位读写数据，尽管IOPS很小，但是每秒读写了N*100M的数据，吞吐量并不小。
(3) 以SQL Server数据库为例
对于OLTP的系统，经常读写小块数据，多为随机访问，用IOPS来衡量读写性能；
对于数据仓库，日志文件，经常读写大块数据，多为顺序访问，用吞吐量来衡量读写性能。
磁盘当前的IOPS，通过以下性能计数器查看：
LogicalDisk/Disk Transfers/sec
LogicalDisk/Disk Reads/sec
LogicalDisk/Disk Writes/sec
磁盘当前的吞吐量，通过以下性能计数器查看：
LogicalDisk/Disk Bytes/sec
LogicalDisk/Disk Read Bytes/sec
LogicalDisk/Disk Write Bytes/sec
❸ Sql server 安全,性能优化的15条方案
1．1 基本概念 与数据库技术密切相关的基本概念包括：数据、数据库、数据库管理系统和数据库系统四大概念。1. 数据（Data） 数据是对客观事物的一种描述，是由能被计算机识别与处理的数值、字符等符号构成的集合，即数据是指描述事物的符号记录。 广义地说，数据是一种物理符号的序列，用于记录事物的情况，是对客观事物及其属性进行的一种抽象化及符号化的描述。数据的概念应包括数据的内容和形式两个方面。数据的内容是指所描述的客观事物的具体特性，也就是通常所说的数据的“值”；数据的形式则是指数据内容所存储的具体形式，即数据的“类型”。故此，数据可以用数据类型和值来表示。2. 数据库（Data Base，DB） 数据库是指长期存储在计算机内部、有组织的、可共享的数据集合，即在计算机系统中按一定的数据模型组织、存储和使用的相关联的数据集合成为数据库。 数据库中的数据按照一定的数据模型组织、描述和存储，具有较小的冗余度、较高的数据独立性、易扩展性、集中性和共享性，以文件的形式存储在存储介质上的。数据库中的数据由数据库管理系统进行统一管理和控制，用户对数据库进行的各种数据操作都是通过数据库管理系统实现。3. 数据库管理系统（Data Base Management System，DBMS） 数据库管理系统是数据库系统的核心，是为数据库的建立、使用和维护而配置的软件，是位于操作系统与用户之间的一层数据管理软件。主要功能是对数据库进行定义、操作、控制和管理。1) 数据定义 数据的定义包括：定义构成数据库结构的外模式、模式和内模式，定义各个外模式和模式之间的映射，定义模式与内模式之间的映射，定义有关的约束条件。2) 数据处理对数据的处理操作主要包括对数据库数据的检索、插入、修改和删除等基本操作。3) 安全管理 对数据库的安全管理主要体现在：对数据库进行并发控制、安全性检查、完整性约束条件的检查和执行、数据库的内部维护（如索引、数据字典的自动维护）等。并且能够管理和监督用户的权限，防止拥护有任何破坏或者恶意的企图。4) 数据的组织、存储和管理 负责分类地组织、存储和管理数据库数据，确定以何种文件结构和存取方式物理地组织数据，如何实现数据之间的联系，以便提高存储空间利用以及提高随机查找、顺序查找、增加、删除和查改等操作的时间效率。5) 建立和维护数据库 建立数据库包括数据库数据的初始化与数据转换等。维护数据库包括数据库的转储与恢复、数据库的重组织与重构造、性能的监视与分析等。6) 数据通信接口提供与其他软件系统进行通信的功能。4. 数据库系统（Data Base System，DBS） 数据库系统指在计算机系统中引入数据库后的系统构成，一般有数据库、数据库管理系统、应用系统、数据库管理员和用户构成。1．2 数据库系统的特点 数据库系统的点主要有：数据的结构化、高共享性、低冗余度、易扩充、较高的独立性（物理数据独立、逻辑数据独立）以及数据由DBMS统一管理和控制（数据的安全性Security保护、数据的完整性Integrity保护、并发Concurrency控制、数据库恢复Recovery）等。第二章 数据库性能优化 数据库作为一种独立的、有组织、的可共享的数据集合，数据的查询访问是数据操作中频度最高的操作。当数据量和访问频率达到一定程度的时候，系统的响应速度就至关重要了，这时候就需要对数据库数据存储的结构和方式进行优化，使其满足系统需要的访问响应速度。2．1 性能影响因素 常见的影响数据访问速度的因素，有以下几种：1. 没有索引或者没有用到索引 数据库索引就像书籍中目录一样，使用户在访问数据库数据时，不必遍历所有数据就可以找到需要的数据。创建索引后，可以保证每行数据的唯一性，极大地提高数据检索效率，这是一中牺牲空间换取性能的方法。没有索引或者没有用到索引是数据访问速度慢最常见的因素，也是程序设计的一个缺陷所在。2. I/O吞吐量小，形成了瓶颈效应 I/O吞吐量是影响数据访问速度的客观因素（硬件因素）。在一定的硬件环境下，利用优化的部署方案可适当提高I/O吞吐量。3. 没有创建计算列导致查询不优化 计算列是一个比较特殊的列，不填写任何设计类型，用户不可以改变该列的值。计算列的值是通过一定的函数公式等以另一个或多个列的值为输入值计算出的结果。如果没相应的计算列，在一些数据查询的时候需要对已有数据进行计算，从而浪费一部分性能。4. 内存不足 对数据库数据的查询访问毫无疑问会占用大量的内存空间，当内存不足的情况下，数据的访问速度会受到明显的影响甚至访问出现超时情况，是影响数据访问速度的客观因素。5. 网络速度慢 网络速度慢是影响数据访问速度的客观因素。可通过提高网络访问的位宽来解决。6. 查询出的数据量过大 当查询出的数据量过大时，内存的占用、系统时间的占用等都影响数据访问的速度。可以采用多次查询、定位查询、和查询数据量控制来解决。7. 锁或者死锁 锁或者死锁在数据库数据访问时会造成访问者等待时间过程或者永久无法获取到资源。这是查询慢最常见的因素之一，是程序设计的缺陷，要尽量避免。8. 返回不必要的行和列 在一般的数据查询中，都尽可能多的获取数据信息，这样造成了不必要的数据遍历，大大的增加了数据访问的响应的时间。所以在一般的查询中，尽量查询少的行和列，将数据遍历时间降到最低以满足数据输出需求。9. 查询语句不够优化 在数据查询访问过程中，使用最频繁的是使用自定义的查询语句进行数据输出的。所以编写优化的查询语句能够很大程度上提高数据查询访问的速度。2．2 性能优化 数据库性能优化主要是提高数据访问的速度，即提高数据库响应速度的性能指标。性能优化主要分为主观因素和客观因素两部分的优化。这里主要针对影响性能的客观因素进行优化。2．2．1 主观因素优化 主观因素主要是指服务器的硬件环境。主要优化有以下几个方面：1、 把数据、日志、索引放到不同的I/O设备上，增加读取速度，数据量越大，提高I/O吞吐量越重要；2、 纵向、横向分割表，减少表的尺寸（sp_spaceuse）；3、 升级硬件；4、 提高网络访问速度；5、 扩大服务器的内存；配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置，一般设置为物理内存的1.5倍；如果安装了全文检索功能，并打算运行Microsoft搜索服务以便执行全文索引和查询，可考虑将虚拟内存大小设置为至少计算机中物理内存的3倍；6、 增加服务器CPU个数；其中并行处理比串行处理更需要资源。SQL SERVER根据系统负载情况决定最优的并行等级，复杂的需要消耗大量的CPU的查询适合并行处理。不过更新操作UPDATE、INSERT、DELETE不能进行并行处理。 2．2．2 客观因素优化 客观因素主要指的是由于设计和开发中存在的缺陷和漏洞；主要优化有以下几个方面：1. 优化索引（1） 根据查询条件建立优化的索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使用字节数小的列建里索引（参照索引的创建），不要对有限的几个值的字段建立单一索引（如性别字段）。（2） 如果使用LIKE进行查询的话，简单的使用INDEX是不行的，全文索引又太耗费空间。LIKE ‘N%’使用索引，LIKE ‘%N’不使用索引。用LIKE‘%N%’查询时，查询耗时和字段值总长度成正比，所以不能用CHAR类型而采用VARCHAR。对于字段的值很长的字段建立全文索引。（3） 重建索引DBCC REINDEX，DBCC INDEXDEFRAG，收缩数据和日志DBCC SHRINKDB，DBCC SHRINKFILE。设置自动收缩日志，对与大的数据库不要设置数据库自动增长，它会降低服务器的性能。2. 数据库部署优化（1） DB SERVER和APPLICATION SERVER分离，OLTP和OLAP分离；（2） 使用分区视图。分布式分区视图可用于实现数据库服务器联合体，联合体是一组分开管理的服务器，他们互相协作分担系统的处理负荷。A、在实现分区视图之前，必须先水平分区表。B、在创建成员表后，在每个服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统操作如同每个成员服务器都有一个原始表的复本一样，不过每个服务器上其实只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。3. 查询语句优化 T-SQL的写法上有很大的讲究，DBMS处理查询计划的过程是：a、查询语句的词法、语法检查；b、将语句提交给DBMS的查询优化器；c、优化器做代数优化和存取路径的优化；d、由预编译模块生成查询规划；e、在合适的时间提交给系统处理执行；f、将执行结果返回给用户。（1） COMMIT和ROLLBACK的区别：ROLLBACK回滚所有的事务；COMMIT提交当前的事务。在动态语句中写事务，请将事务写在外面，如：BEGIN TRAN EXEC（@SQL） COMMIT TRANS或者将动态SQL写成函数或者存储过程。（2） 在大数据两的查询输出SELECT语句中尽量不要使用自定义函数，调用自定义函数的函数时系统调用是一个迭代过程，很影响查询输出性能的。在查询字段时尽可能使用小字段两输出，并在WHERE子句或者使用SELECT TOP 10/1 PERCENT来限制返回的记录数，使用SET ROWCOUNT来限制操作的记录数，避免整表扫描。返回不必要的数据，不但浪费了服务器的I/O资源，加重了网络的负担，如果表很大的话，在表扫描期间将表锁住，禁止其他的联接访问，后过很严重的。（3） SQL的注释申明对执行查询输出没有任何影响。（4） 使用计算列对数据进行简单计算，尽量避免在查询语句中对数据进行运算。（5） 尽可能不使用光标，它会占用大量的资源。如果需要ROW-BY-ROW地执行，尽量采用非光标技术，如：客户端循环、临时表、TABLE变量、子查询、CASE语句等等。（6） 使用PROFILER来跟踪查询，得到查询所需的时间，找出SQL的问题所在，用索引优化器优化索引。（7） 注意UNION和UNION ALL的区别。在没有必要的时候不要用DISINCT，它同UNION一样会降低查询速度，重复的记录在查询里是没有问题的。（8） 用sp_configure ‘query governor cost limit’或者 SET QUERY_COVERNOR_COST_LIMIT来限制查询消耗的资源。当评估查询消耗的 资源超出限制时，服务器自动取消查询，在查询之前就扼杀掉。SET LOCKTIME 设置锁的时间。（9） 不要在WHERE子句中列名加函数，如CONVERT，SUBSTRING等，如果必须用函数的时候，创建计算列在创建索引来替代。NOT IN会多次扫描表，使用EXISTS、NOT EXISTS、IN、LEFT OUTER JOIN来替代，其中EXISTS比IN更快，最慢的NOT操作。（10） 使用QUERY ANALYZER，查看SQL语句的查询计划和评估分析是否是优化的SQL。一般20%的代码占用了80%的资源，优化的重点就是这些慢的地方。（11） 如果使用了IN或者OR等时发现查询没有走索引，使用显式申明指定索引，如：Select * From FA01(INDEX=IX_SEX) Where AA0107 IN(‘01’,‘02’)。（12） 在需要对已有数据进行比较复杂计算才能获得查询的结果数据时,将需要查询的结果预先计算好放在表中,查询的时候在SELECT。（13） 数据库有一个原则是代码离数据越近越好，所有有限选择DEFAULT，依次为RULES，CONSTRAINT，PROCEDURE来编写程序的质量高，速度快。如果要插入大的二进制到IMAGE列，使用存储过程，千万不要用内嵌INSERT直接插入。因为这样应用程序首先将二进制转换成字符串，服务器收到字符后又将他转换成二进制。存储过程直接传入二进制参数即可，处理速度明显改善，如：CREATE PROCEDURE image_insert @image varbinary as Insert into table(fImage) values(@image)。（14） Between在某些时候比IN速度更快，更快地根据索引找到范围。由于IN会比较多次，所以有时会慢些。（15） 尽量不要建没有作用的事务例如产生报表时，浪费资源，只有在必须使用事务时才建立合适的事务。（16） 用OR的字句可以分解成多个查询，并通过UNION连接多个查询。速度取决与是否使用索引。如果查询需要用联合索引，用UNION ALL执行的效率更高些。（17） 尽量少用视图，视图的效率低。对视图操作比直接对表操作慢，可以用SRORED PROCEDURE来代替。特别是不要用视图嵌套，嵌套视图增加了寻找原始资料的难度。视图是存放在服务器上的被优化好了的已经产生查询规划的SQL。对单表数据检索时，不要使用指向多表的视图，否则增加了不必要的系统开销，查询也会受到干扰。没有必要时不要用DISTINCT和ORDER BY，这些动作可以改在客户端执行，增加了额外的开销，这同UNION和UNION ALL原理相同。（18） 当使用SELECT INTO和CREATE TABLE时，会锁住系统表（SYSOBJECTS，SYSINDEXES等），从而阻塞其他的连接的存取。所以千万不要在事务内部使用。如果经常要用到临时表时请使用实表或者临时表变量。尽量少用临时表，用结果集和TABLE类型的变量来代替。（19） 在使用GROUP BY HAVING子句时，在使用前剔除多余的行，尽量避免使用HAVING子句剔除行工作。剔除行最优的执行顺序是：SELECT的WHERE子句选择所有合适的行，GROUP
❹ access中使用sql语句not in效率太低，有没有效率高的办法啊
数据量多的话 ACCESS本身效率就会变低 access效率就是和数据量多少成反比的 建议换成SQL的数据库好了
❺ nvarchar及nvarchar中的n及max是否会影响性能 实例分析
view plain to clipboardprint?
----------------------------------------------------------------------------------
-- Subject : nvarchar(n)及nvarchar(max)中的n及max是否会影响性能
-- Author : 柳永法(yongfa365) http://www.yongfa365.com/ [email protected]
-- CreateDate : 2010-11-22 23:31:04
-- Environment : Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (Intel X86)
-- Apr 2 2010 15:53:02
-- Copyright (c) Microsoft Corporation
-- Enterprise Evaluation Edition on Windows NT 5.2 <x86></x86> (Build 3790: Service Pack 2)
----------------------------------------------------------------------------------
--首先创建两个表，一个放nvarchar(4000),一个放nvarchar(max)
CREATE TABLE [dbo].[testnvarchar4000] (
id int IDENTITY (1, 1) ,
cnt nvarchar(4000)
)
GO
CREATE TABLE [dbo].[testnvarcharmax] (
id int IDENTITY (1, 1) ,
cnt nvarchar(max)
)
GO
--然后插入10万条数据，每个cnt里放4000个字符(nvarchar(n)里n的最大值)，大约1.6G
BEGIN TRANSACTION
DECLARE @i INT ;
SET @i = 0 ;
while @i<100000
begin
insert into [testnvarchar4000] values(LEFT(REPLICATE(cast(@i as nvarchar)+'我是柳永法',1000),4000))
insert into [testnvarcharmax] values(LEFT(REPLICATE(cast(@i as nvarchar)+'我是柳永法',1000),4000))
set @i=@i+1
END
COMMIT
--清空缓存，或重启SQL服务，测试查询速度及lob读取情况(lob是大对象的意思)
--测试testnvarcharmax
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
SET STATISTICS IO ON
SET STATISTICS TIME ON
SELECT COUNT(*)
FROM testnvarcharmax
WHERE cnt LIKE '%柳永法%'
SET STATISTICS TIME OFF
SET STATISTICS IO OFF
--测试testnvarchar4000
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
SET STATISTICS IO ON
SET STATISTICS TIME ON
SELECT COUNT(*)
FROM testnvarchar4000
WHERE cnt LIKE '%柳永法%'
SET STATISTICS TIME OFF
SET STATISTICS IO OFF
--结果：
--(1 行受影响)
--表 'testnvarcharmax'。扫描计数 3，逻辑读取 100000 次，物理读取 8494 次，预读 99908 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
--
-- SQL Server 执行时间:
-- CPU 时间 = 1172 毫秒，占用时间 = 30461 毫秒。
--(1 行受影响)
--表 'testnvarchar4000'。扫描计数 3，逻辑读取 100000 次，物理读取 8523 次，预读 99916 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
--
-- SQL Server 执行时间:
-- CPU 时间 = 968 毫秒，占用时间 = 30038 毫秒。
--从结果可以看出，这两次读取时间基本相同，并且都没有lob读取，以上数据为多次测试结果。
--给testnvarcharmax前1000条字段长度+1,来测试是不是超过4000字就会使用lob读取
UPDATE testnvarcharmax SET cnt=cnt+'1' WHERE id <=1000
--结果：
--(1 行受影响)
--表 'testnvarcharmax'。扫描计数 3，逻辑读取 100000 次，物理读取 8292 次，预读 99696 次，lob 逻辑读取 900 次，lob 物理读取 83 次，lob 预读 0 次。
--
-- SQL Server 执行时间:
-- CPU 时间 = 1124 毫秒，占用时间 = 30318 毫秒。
--此结果显示使用了lob读取。但时间相差也不太大。
--字段值加倍，再测试：
UPDATE testnvarcharmax SET cnt=cnt+cnt WHERE id <=1000
--结果：
--(1 行受影响)
--表 'testnvarcharmax'。扫描计数 3，逻辑读取 100000 次，物理读取 8164 次，预读 99521 次，lob 逻辑读取 1000 次，lob 物理读取 101 次，lob 预读 0 次。
--
-- SQL Server 执行时间:
-- CPU 时间 = 1094 毫秒，占用时间 = 31095 毫秒。
从以上结果基本上可以证明自己文章头提到的观点，nvarchar(n)或nvarchar(max)中的n及max只是一个符号，不会影响占用空间及性能，除非max存储字符数大于4000，所以我们只要关注实际业务需要就可以了
❻ 开启mysql慢查询 的话 对系统性能影响大么
这是一个慢查询日志的展示工具，能够帮助 DBA 或者开发人员分析数据库的性能问题，给出全面的数据摆脱直接查看 slow-log。QAN（Query Analytics）
PMM 目前有 2 个版本，但是对于 QAN 来说其大致由三部分组成：
QAN-Agent（client）：负责采集 slow-log 的数据并上报到服务端
QAN-API（server）：负责存储采集的数据，并对外提供查询接口
QAN-APP：专门用来展示慢查询数据的 grafana 第三方插件
1. 数据流转
slow-log --> QAN-Agent --> QAN-API <--> QAN-APP（grafana）
2. pmm1 架构图
❼ 武新：海量数据环境下如何提升I/O效率
一般而言，解决这三大性能瓶颈的手段主要有两个，即硬件改进与软件优化。 南大通用数据技术有限公司武新 所谓的硬件改进是一种被动的优化手段，主要是通过提升硬件来对系统进行扩容和优化。之所说这种方式较为被动，主要在于这需要提供巨大的成本，而且扩容的效果是有限的，不可能无限扩容，不是数据库性能优化的根本之道。更为主要的是，体现不出DBA的价值，DBA首先应该想到的是利用主动的方式去对数据库性能进行优化。 对数据库优化的方式主要分为三个手段，如修改数据模型、修改SQL、影响CBO，以产生有效的SQL执行计划;另外也可适用索引、MV等工具;第三种方式则是使用并行，充分利用SMP的特征。不管采用何种方式对数据库性能进行优化，我们要明确的是，数据库性能优化的核心思想是提升查询SQL的I/O效率。 另外我们还需要明白有关I/O的两个定义，即I/O速度与I/O效率。I/O速度是I/O数据量与时间的比值，其单位是MB/s;而I/O效率是有效数据与实际I/O数据量的比值，其结果是一个百分比值。并且I/O速度与I/O效率并没有相关性，通过硬件扩容只能提升I/O性能，并不能提高I/O效率。I/O效率是衡量不同数据库面对海量数据统计、分析性能差异最关键的指标、也是现代数据库研发最核心的问题之一。 数据库性能最核心的问题之一是I/O效率低下，解决这个问题主要有以下几个方式：1、使用不同索引定位需要的数据;2、产生高效的SQL执行计划;3、提升每次I/O包含的有效数据量;4、对数据进行预计算(MV);5、使用分区技术、压缩技术。 数据库性能最核心的问题之二是传统索引带来的矛盾。使用索引的最大作用是提升I/O效率。但其产生的问题也不少，如对应用不透明、维护代价极高以及需要人工优化等等。不使用索引的好处显而易见，无需维护，并且数据入库速度快，但查询I/O效率低、导致性能低下。这是使用或不适用传统索引所带来的矛盾，不管用还是不用，都会给数据库性能带来一定的影响。因此海量环境下的数据库分析需要一种新的索引方式，在此，南大通用数据库公司的武新给我们介绍了一种新的索引方式，即在GBase 8a中所用到的列存储+粗粒度索引的方式。 这种方式主要有一下几个特点，粗粒度的扩展性很高，几乎不会对数据入库性能造成影响;其次，局部性实现高效的数据边入库边查询、统计，数据入库速度不随数据量增加而降低，;并且，全字段索引使得不需要再手工建立索引。
❽ sql函数与string拼接查询id集合哪个效率高
由于SQL面向结面向程查询语言所般支持SQL语言型关系型数据库都使用基于查询本优化器即查询提供佳执行策略于优化器输入条查询语句输执行策略 条SQL查询语句种执行策略优化器估计全部执行所需间少所谓本低种所优化都基于用记所使用查询语句where句优化器where句优化主要用搜索参数(Serach Argument) 搜索参数核思想数据库使用表字段索引查询数据必直接查询记录数据 带 =、<、、>= 等操作符条件语句直接使用索引列搜索参数： emp_id = "10001" 或 salary > 3000 或 a =1 and c = 7 列则搜索参数： salary = emp_salary 或 dep_id != 10 或 salary * 12 >= 3000 或 a=1 or c=7 应尽能提供些冗余搜索参数使优化器更选择余请看3种： 第种： select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (department.dep_code='01') and (employee.dep_code='01'); 搜索析结： Estimate 2 I/O operations Scan department using primary key for rows where dep_code equals '01' Estimate getting here 1 times Scan employee sequentially Estimate getting here 5 times 第二种： select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (department.dep_code='01'); 搜索析结： Estimate 2 I/O operations Scan department using primary key for rows where dep_code equals '01' Estimate getting here 1 times Scan employee sequentially Estimate getting here 5 times 第种与第二种运行效率相同第种优化器提供更选择机 第三种： select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (employee.dep_code='01'); 种使用索引优化…… 使用SQL语句应注意几点： 1、避免使用兼容数据类型例 Binary兼容数据类型兼容能使优化器执行些本进行优化操作例： select emp_name form employee where salary > 3000; 语句若salaryFloat类型则优化器难其进行优化3000整数我应编程使用3000.0要等运行让DBMS进行转化 2、尽量要使用表达式编绎所SQL能使用其平均密度估计要命记录数 3、避免搜索参数使用其数操作符： select emp_name from employee where salary * 12 > 3000; 应改： select emp_name from employee where salary > 250; 4、避免使用 != 或 > 等操作符使系统使用索引能直接搜索表数据 目前,几乎所应用程序都要数据库打交道通查询数据库容易获想要数据,令满意:某些查询间,响应速度慢究其原,硬件设备(CPU、磁盘)存取速度跟,内存容量够,需要计算机制造商努力;另面没进行查询优化本文查询优化问题,谈点实践体 解查询 种查询解执行,根据付销少决定何解,何执行便叙述,先给例 关系:SUPPLIER(S#,SNAME,CITY) :S(关键字) PARTS (P#,PNAME,SIZE) :P(关键字) PROJECT (J#,JNAME,COLOR) :J(关键字) INVENTORY(S#,P#,QO) :V(关键字) SUPPLY(S#,J#,P#,QU) :Y(关键字) 其,QO:现数量 QU:要用数量 查询找某城市能提供黑色轿车,且供应量于1000供应商名单 1. 般查询 (1) 形卡氏积 S×P×J×V×Y; (2) 卡氏积选择满足条件元组; (3) S.SNAME投影 5元查询查询涉及卡氏积,卡氏积元组数组合性增,仅需要量存储空间,且执行查询间 2. 优化查询 该查询解处理介绍两种: (1) 元查询提取任N元查询Q(X1,X2......Xn)替换元查询Q1其执行Q2,即Q→(Q1,Q2) (2) 化简 Q替换两查询Q1Q2,Q2Q1执行执行,变化,即Q1(X1,X2......Xm), Q2(Xm,Xm+1......Xn) 例例查询两元查询 SELECTP# FROMP WHEREP.PNAME=‘轿车’ AND P.COLOR=‘黑色’ SELECTS#,J#,P#,QO FROMY WHEREV.QO>1000 另部查询: SELECTS.SNAME FROMS,P,J,V,Y WHERE (S.S#=V.S# AND S.S#=Y.S# AND S.CITY=J.CITY AND P.P#=V.P# AND T.P#=V.P# AND J.J#=Y.J#) 面例查询容易化简化涉及(P,V)查询其执行涉及(S,J,Y,V)查询: SELECTS.SNAME FORMS,J,V,Y WHERES.CITY=J.CITY AND S.S#=Y.S# AND J.J#=Y.J# AND V.QO>1000 AND P.#=Y.P# AND V.S#=Y.S# AND V.P#=(SELECT V.P# FROM V,P WHERE V.P#=P P#AND P.PNAME=‘轿车’ ANDP.COLOR=‘黑色’) 3. 综所述 元查询提取几乎总处,关系运算前尽能减少关系体积减少相应系统销起作用;·通期待优化结,并绝 选择优存取路径 计算查询表达式值要充考虑索引、数据存储布等存取路径,进步提高查询效率例,选择字段、连接字段否索引,利用索引HASHING算快速存取包含索引属性特定值记录建立索引,用户按顺序读文件记录,依照接近于物理顺序顺序读文件记录非效种接近物理顺序读取文件记录索引称聚簇索引聚簇索引使我利用存储块记录物理聚簇优点,加快查询速度面具体谈点实践体 前久,笔者参加内发外数据库应用系统编程工作该系统台使用Oracle 7.3数据库,OracleDBMS处理SQL执 行语句顺序: (1) 根据WHERE句选择行; (2) 根据GROUP BY句些行进行聚合; (3) 每组用组函数计算结; (4) 根据HAVING句选择排除组; (5) 根据ORDER BY句组函数所结组进行排序 体现查询优化思路执行顺序,查询性能具直接影响般说,WHERE句滤记录越,查询速度越快减少GROUP BY运算必须处理行数量工作笔者体 1. 尽量避免连接 例: PowerBuilder 5.0数据窗口选择库表自各表相同属性名(域相同)连接起种自连接数情况益,些情况却需要取消连接查询条件P2000、P3000、P4000效区都1,两种: (1) WHERE(P2000.效区=P3000.效区 P3000.效区=P4000.效区 P2000.效区=1 (2) WHERE(P2000.效区=1 P3000.效区=1 P4000.效区=1 第种自基础添加P2000.效区=1,第二种先要取消连接,再重新写WHERE语句表面看,第种简单,其实第种降低执行效率,必要连接所笔者提醒使用者,要省事降低系统效率 2. 选择佳解决案 解决同问题固,应用应该选择佳解决例,某问题数据库查询两种,执行结,效率却同 查询要求:程序运行界面输入负责代码(放code),查询P2000表负责代码等于code负责名;没输入负责代码,查询P2000表所负责名负责代码取值范围0～9999,两种解决别: (1) IF 没输入负责代码 THEN code1=0 code2=9999 ELSE code1=code2=负责代码 END IF 执行SQL语句: SELECT 负责名 FROM P2000 WHERE 负责代码>=:code1 AND负责代码 1001) OR order_num=1008 虽customer_numorder_num建索引面语句优化器使用顺序存取路径扫描整表语句要检索离行集合所应该改语句： SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001 UNION SELECT ＊ FROM orders WHERE order_num=1008 能利用索引路径处理查询 4．避免相关查询 列标签同主查询where句查询现能主查询列值改变查询必须重新查询查询嵌套层越效率越低应尽量避免查询查询避免要查询滤掉尽能行 5．避免困难规表达式 MATCHESLIKE关键字支持通配符匹配技术叫规表达式种匹配特别耗费间例：SELECT ＊ FROM customer WHERE zipcode LIKE 98_ _ _ 即使zipcode字段建立索引种情况采用顺序扫描式语句改SELECT ＊ FROM customer WHERE zipcode >98000执行查询利用索引查询显提高速度 另外要避免非始串例语句：SELECT ＊ FROM customer WHERE zipcode[23] >80where句采用非始串语句使用索引 6．使用临表加速查询 表集进行排序并创建临表能加速查询助于避免重排序操作且其面能简化优化器工作例： SELECT cust.namercvbles.balance……other columns FROM custrcvbles WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance>0 AND cust.postcode>98000 ORDER BY cust.name 查询要执行止所未付款客户找放临文件并按客户名字进行排序： SELECT cust.namercvbles.balance……other columns FROM custrcvbles WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance>0 ORDER BY cust.name INTO TEMP cust_with_balance 面式临表查询： SELECT ＊ FROM cust_with_balance WHERE postcode>98000 临表行要比主表行少且物理顺序所要求顺序减少磁盘I/O所查询工作量幅减少 注意：临表创建反映主表修改主表数据频繁修改情况注意要丢失数据 7．用排序取代非顺序存取 非顺序磁盘存取慢操作表现磁盘存取臂移SQL语句隐藏情况使我写应用程序容易写要求存取量非顺序页查询 些候用数据库排序能力替代非顺序存取能改进查询 数据库查询优化技术(2) 际 实例析 面我举制造公司例说明何进行查询优化制造公司数据库包括3表模式所示： 1．part表 零件号 零件描述 其列 （part_num） （part_desc） （other column） 102032 Seageat 30G disk …… 500049 Novel 10M network card …… …… 2．vendor表 厂商号 厂商名 其列 （vendor _num） （vendor_name） （other column） 910257 Seageat Corp …… 523045 IBM Corp …… …… 3．parven表 零件号 厂商号 零件数量 （part_num） （vendor_num） （part_amount） 102032 910257 3,450,000 234423 321001 4000000 …… 面查询些表定期运行并产关于所零件数量报表： SELECT part_descvendor_namepart_amount FROM partvendorparven WHERE part.part_num=parven.part_num AND parven.vendor_num = vendor.vendor_num ORDER BY part.part_num 建立索引述查询代码销十巨我零件号厂商号建立索引索引建立避免嵌套反复扫描关于表与索引统计信息： 表 行尺寸 行数量 每页行数量 数据页数量 （table） (row size) （Row count） （Rows/Pages） （Data Pages） part 150 10000 25 400 Vendor 150 1000 25 40 Parven 13 15000 300 50 索引 键尺寸 每页键数量 页面数量 （Indexes） (Key Size) （Keys/Page) (Leaf Pages） part 4 500 20 Vendor 4 500 2 Parven 8 250 60 看起相简单3表连接其查询销通查看系统表看part_numvendor_num簇索引索引按照物理顺序存放parven表没特定存放序些表说明缓冲页非顺序存取功率语句优化查询规划：首先part顺序读取400页再parven表非顺序存取1万每2页（索引页、数据页）总计2万磁盘页vendor表非顺序存取1.5万合3万磁盘页看索引连接花费磁盘存取5.04万 实际我通使用临表3步骤提高查询效率： 1．parven表按vendor_num序读数据： SELECT part_numvendor_numprice FROM parven ORDER BY vendor_num INTO temp pv_by_vn 语句顺序读parven（50页）写临表（50页）并排序假定排序销200页总共300
❾ mysql怎样高效率随机获取n条数据
数据库优化有很多可以讲，按照支撑的数据量来分可以分为两个阶段：单机数据库和分库分表，前者一般可以支撑500W或者10G以内的数据，超过这个值则需要考虑分库分表。另外，一般大企业面试往往会从单机数据库问起，一步一步问到分库分表，中间会穿插很多数据库优化的问题。本文试图描述单机数据库优化的一些实践，数据库基于mysql，如有不合理的地方，欢迎指正。
1、表结构优化
在开始做一个应用的时候，数据库的表结构设计往往会影响应用后期的性能，特别是用户量上来了以后的性能。因此，表结构优化是一个很重要的步骤。
1.1、字符集
一般来说尽量选择UTF-8，虽然在存中午的时候GBK比UTF-8使用的存储空间少，但是UTF-8兼容各国语言，其实我们不必为了这点存储空间而牺牲了扩展性。事实上，后期如果要从GBK转为UTF-8所要付出的代价是很高的，需要进行数据迁移，而存储空间完全可以用花钱扩充硬盘来解决。
1.2、主键
在使用mysql的innodb的时候，innodb的底层存储模型是B+树，它使用主键作为聚簇索引，使用插入的数据作为叶子节点，通过主键可以很快找到叶子节点，从而快速获取记录。因此在设计表的时候需要增加一个主键，而且最好要自增。因为自增主键可以让插入的数据按主键顺序插入到底层的B+树的叶子节点中，由于是按序的，这种插入几乎不需要去移动已有的其它数据，所以插入效率很高。如果主键不是自增的，那么每次主键的值近似随机，这时候就有可能需要移动大量数据来保证B+树的特性，增加了不必要的开销。
1.3、字段
1.3.1、建了索引的字段必须加上not null约束，并且设置default值
1.3.2、不建议使用float、double来存小数，防止精度损失，建议使用decimal
1.3.3、不建议使用Text/blob来保存大量数据，因为对大文本的读写会造成比较大的I/O开销，同时占用mysql的缓存，高并发下会极大的降低数据库的吞吐量，建议将大文本数据保存在专门的文件存储系统中，mysql中只保存这个文件的访问地址，比如博客文章可以保存在文件中，mysql中只保存文件的相对地址。
1.3.4、varchar类型长度建议不要超过8K。
1.3.5、时间类型建议使用Datetime，不要使用timestamp，虽然Datetime占用8个字节，而timestamp只占用4个字节，但是后者要保证非空，而且后者是对时区敏感的。
1.3.6、建议表中增加gmt_create和gmt_modified两个字段，用来记录数据创建的修改时间。这两个字段建立的原因是方便查问题。
1.4、索引创建
1.4.1、这个阶段由于对业务并不了解，所以尽量不要盲目加索引，只为一些一定会用到索引的字段加普通索引。
1.4.2、创建innodb单列索引的长度不要超过767bytes，如果超过会用前255bytes作为前缀索引
1.4.3、创建innodb组合索引的各列索引长度不要超过767bytes，一共加起来不要超过3072bytes
2、SQL优化
一般来说sql就那么几种：基本的增删改查，分页查询，范围查询，模糊搜索，多表连接
2.1、基本查询
一般查询需要走索引，如果没有索引建议修改查询，把有索引的那个字段加上，如果由于业务场景没法使用这个字段，那么需要看这个查询调用量大不大，如果大，比如每天调用10W+，这就需要新增索引，如果不大，比如每天调用100+，则可以考虑保持原样。另外，select * 尽量少用，用到什么字段就在sql语句中加什么，不必要的字段就别查了，浪费I/O和内存空间。
2.2、高效分页
limit m,n其实质就是先执行limit m+n，然后从第m行取n行，这样当limit翻页越往后翻m越大，性能越低。比如
select * from A limit 100000,10，这种sql语句的性能是很差的，建议改成下面的版本:
selec id,name,age from A where id >=(select id from A limit 100000,1) limit 10
2.3、范围查询
范围查询包括between、大于、小于以及in。Mysql中的in查询的条件有数量的限制，若数量较小可以走索引查询，若数量较大，就成了全表扫描了。而between、大于、小于等，这些查询不会走索引，所以尽量放在走索引的查询条件之后。
2.4、模糊查询like
使用 like %name%这样的语句是不会走索引的，相当于全表扫描，数据量小的时候不会有太大的问题，数据量大了以后性能会下降的很厉害，建议数据量大了以后使用搜索引擎来代替这种模糊搜索，实在不行也要在模糊查询前加个能走索引的条件。
2.5、多表连接
子查询和join都可以实现在多张表之间取数据，但是子查询性能较差，建议将子查询改成join。对于mysql的join，它用的是Nested Loop Join算法，也就是通过前一个表查询的结果集去后一个表中查询，比如前一个表的结果集是100条数据，后一个表有10W数据，那么就需要在100*10W的数据集合中去过滤得到最终的结果集。因此，尽量用小结果集的表去和大表做join，同时在join的字段上建立索引，如果建不了索引，就需要设置足够大的join buffer size。如果以上的技巧都无法解决join所带来的性能下降的问题，那干脆就别用join了，将一次join查询拆分成两次简单查询。另外，多表连接尽量不要超过三张表，超过三张表一般来说性能会很差，建议拆分sql。
3、数据库连接池优化
数据库连接池本质上是一种缓存，它是一种抗高并发的手段。数据库连接池优化主要是对参数进行优化，一般我们使用DBCP连接池，它的具体参数如下：
3.1 initialSize
初始连接数，这里的初始指的是第一次getConnection的时候，而不是应用启动的时候。初始值可以设置为并发量的历史平均值
3.2、minIdle
最小保留的空闲连接数。DBCP会在后台开启一个回收空闲连接的线程，当该线程进行空闲连接回收的时候，会保留minIdle个连接数。一般设置为5，并发量实在很小可以设置为1.
3.3、maxIdle
最大保留的空闲连接数，按照业务并发高峰设置。比如并发高峰为20，那么当高峰过去后，这些连接不会马上被回收，如果过一小段时间又来一个高峰，那么连接池就可以复用这些空闲连接而不需要频繁创建和关闭连接。
3.4、maxActive
最大活跃连接数，按照可以接受的并发极值设置。比如单机并发量可接受的极值是100，那么这个maxActive设置成100后，就只能同时为100个请求服务，多余的请求会在最大等待时间之后被抛弃。这个值必须设置，可以防止恶意的并发攻击，保护数据库。
3.5、maxWait
获取连接的最大等待时间，建议设置的短一点，比如3s，这样可以让请求快速失败，因为一个请求在等待获取连接的时候，线程是不可以被释放的，而单机的线程并发量是有限的，如果这个时间设置的过长，比如网上建议的60s，那么这个线程在这60s内是无法被释放的，只要这种请求一多，应用的可用线程就少了，服务就变得不可用了。
3.6、minEvictableIdleTimeMillis
连接保持空闲而不被回收的时间，默认30分钟。
3.7、validationQuery
用于检测连接是否有效的sql语句，一般是一条简单的sql，建议设置
3.8、testOnBorrow
申请连接的时候对连接进行检测，不建议开启，严重影响性能
3.9、testOnReturn
归还连接的时候对连接进行检测，不建议开启，严重影响性能
3.10、testWhileIdle
开启了以后，后台清理连接的线程会没隔一段时间对空闲连接进行validateObject，如果连接失效则会进行清除，不影响性能，建议开启
3.11、numTestsPerEvictionRun
代表每次检查链接的数量，建议设置和maxActive一样大，这样每次可以有效检查所有的链接。
3.12、预热连接池
对于连接池，建议在启动应用的时候进行预热，在还未对外提供访问之前进行简单的sql查询，让连接池充满必要的连接数。
4、索引优化
当数据量增加到一定程度后，靠sql优化已经无法提升性能了，这时候就需要祭出大招：索引。索引有三级，一般来说掌握这三级就足够了，另外，对于建立索引的字段，需要考虑其选择性。
4.1、一级索引
在where后面的条件上建立索引，单列可以建立普通索引，多列则建立组合索引。组合索引需要注意最左前缀原则。
4.2、二级索引
如果有被order by或者group by用到的字段，则可以考虑在这个字段上建索引，这样一来，由于索引天然有序，可以避免order by以及group by所带来的排序，从而提高性能。
4.3、三级索引
如果上面两招还不行，那么就把所查询的字段也加上索引，这时候就形成了所谓的索引覆盖，这样做可以减少一次I/O操作，因为mysql在查询数据的时候，是先查主键索引，然后根据主键索引去查普通索引，然后根据普通索引去查相对应的记录。如果我们所需要的记录在普通索引里都有，那就不需要第三步了。当然，这种建索引的方式比较极端，不适合一般场景。
4.4、索引的选择性
在建立索引的时候，尽量在选择性高的字段上建立。什么是选择性高呢？所谓选择性高就是通过这个字段查出来的数据量少，比如按照名字查一个人的信息，查出来的数据量一般会很少，而按照性别查则可能会把数据库一半的数据都查出来，所以，名字是一个选择性高的字段，而性别是个选择性低的字段。
5、历史数据归档
当数据量到了一年增加500W条的时候，索引也无能为力，这时候一般的思路都是考虑分库分表。如果业务没有爆发式增长，但是数据的确在缓慢增加，则可以不考虑分库分表这种复杂的技术手段，而是进行历史数据归档。我们针对生命周期已经完结的历史数据，比如6个月之前的数据，进行归档。我们可以使用quartz的调度任务在凌晨定时将6个月之前的数据查出来，然后存入远程的hbase服务器。当然，我们也需要提供历史数据的查询接口，以备不时之需。
以上就是对mysql 单机数据库的优化资料整理，后续继续补充相关资料，谢谢大家对本站的支持！
❿ sql语句联合查询 与 视图想比较的话，那个效率快，为什么。
sql效率比较快，存储过程的好处是不仅快且更安全，但移植性差。视图可以封装查询的复杂性，就像面向对象里类的概念一样。