& mysql数据库千万级别数据的查询优化和分页测试
mysql数据库千万级别数据的查询优化和分页测试
mysql数据库千万级别数据的查询优化和分页测试
我原来的公司是一家网络游戏公司,其中网站交易与游戏数据库结合通过ws实现的,但是交易记录存放在网站上,级别是千万级别的数据库是mysql数据库.
可能有人会问mysql是否支持千万级数据库,还有既然已经到了这个数据量公司肯定不差,为什么要用mysql而不用oracle这里我做一下解答
1. mysql绝对支持千万级数据库是可以肯定的，
2. 为什么选择择mysql呢？
1& 第一也是最主要的一条是mysql他能做到。
2& 在第一点前提下以下的就不是太重要了,mysql相对操作简单,测试容易,配置优化也相对容易很多
3& 我们这里的数据仅仅是为了记录交易保证交易是被记录的,对于查询的还是相对少只有管理后台操作中需要对数据库进行查询
4& 数据结构简单,而且每条记录都非常小,因为查询速度不管和记录条数有关和数据文件大小也有直接关系.
5& 我们采用的是大小表的解决办法,每天大概需要插入数据库好几百万条,这里可能还是有人怀疑,其实没问题,如果批量插入我测试的在普通的pc机子上带该一个 线程并发我插入的是6千万条记录大概需要“JDBC插入6000W条数据用时:9999297ms”,小表保存最近插入的内容,把几天前的保存到大表中, 这里我说的就是大表大概6-7千万条数据;
带着这些疑问和求知欲望咱们来做一个测试，因为在那个时候我也不是dba不知道人家是怎么搞的能够做成这么大的数据量,我们平时叶总探讨一些相关的内容
1.mysql的数据查询,大小字段要分开,这个还是有必要的,除非一点就是你查询的都是索引内容而不是表内容,比如只查询id等等
2.查询速度和索引有很大关系也就是索引的大小直接影响你的查询效果,但是查询条件一定要建立索引,这点上注意的是索引字段不能太多，太多索引文件就会很大那样搜索只能变慢,
3.查询指定的记录最好通过Id进行in查询来获得真实的数据.其实不是最好而是必须，也就是你应该先查询出复合的ID列表,通过in查询来获得数据
我们来做一个测试ipdatas表：
CREATE TABLE `ipdatas` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`uid` INT(8) NOT NULL DEFAULT ,
`ipaddress` VARCHAR(50) NOT NULL,
`source` VARCHAR(255) DEFAULT NULL,
`track` VARCHAR(255) DEFAULT NULL,
`entrance` VARCHAR(255) DEFAULT NULL,
`createdtime` DATETIME NOT NULL DEFAULT &#-00 00:00:00’,
`createddate` DATE NOT NULL DEFAULT &#-00’,
PRIMARY KEY (`id`),
KEY `uid` (`uid`)
) ENGINE=MYISAM AUTO_INCREMENT= DEFAULT CHARSET=utf8;
这是我们做的广告联盟的推广ip数据记录表，由于我也不是mysql的DBA所以这里咱们仅仅是测试
因为原来里面有大概7015291条数据
这里我们通过jdbc的batch插入6000万条数据到此表当中“JDBC插入6000W条数据用时:9999297ms”；
大概用了两个多小时,这里面我用的是batch大小大概在1w多每次提交,还有一点是每次提交的数据都很小，而且这里用的myisam数据表，因为我需要知道mysql数据库的大小以及索引数据的大小结果是
ipdatas.MYD 3.99 GB (4,288,979,008 字节)
ipdatas.MYI 1.28 GB (1,377,600,512 字节)
这里面我要说的是如果真的是大数据如果时间需要索引还是最好改成数字字段,索引的大小和查询速度都比时间字段可观。
1.全表搜索
返回结构是条数据
SELECT COUNT(id) FROM
SELECT COUNT(uid) FROM
SELECT COUNT(*) FROM
首先这两个全表数据查询速度很快,mysql中包含数据字典应该保留了数据库中的最大条数
查询索引条件
SELECT COUNT(*) FROM ipdatas WHERE uid=1;
返回结果时间:2分31秒594
SELECT COUNT(id) FROM ipdatas WHERE uid=1;
返回结果时间:1分29秒609
SELECT COUNT(uid) FROM ipdatas WHERE uid=1; 返回结果时间:2分41秒813
第二次查询都比较快因为mysql中是有缓存区的所以增大缓存区的大小可以解决很多查询的优化，真可谓缓存无处不在啊在程序开发中也是层层都是缓存
第一条开始查询
SELECT * FROM ipdatas ORDER BY id DESC LIMIT 1,10 ; 31毫秒
SELECT * FROM ipdatas LIMIT 1,10 ; 15ms
第10000条开始查询
SELECT * FROM ipdatas ORDER BY id ASC LIMIT 10000,10 ; 266毫秒
SELECT * FROM ipdatas LIMIT 10000,10 ; 16毫秒
第500万条开始查询
SELECT * FROM ipdatas LIMIT
SELECT * FROM ipdatas ORDER BY id ASC LIMIT
; 221.985秒
这两条返回结果完全一样,也就是mysql默认机制就是id正序然而时间却大相径庭
第5000万条开始查询
SELECT * FROM ipdatas LIMIT
;66.563秒 (对比下面的测试)
SELECT * FROM ipdatas ORDER BY id ASC LIMIT ; 秒
SELECT * FROM ipdatas ORDER BY id DESC LIMIT ; 434.937秒
第三条和第二条结果一样只是排序的方式不同但是用时却相差不少，看来这点还是不如很多的商业数据库,像oracle和sqlserver等都是中间不成两边还是没问题，看来mysql是开始行越向后越慢，这里看来可以不排序的就不要排序了性能差距巨大,相差了20多倍
查询数据返回ID列表
第一条开始查
select id from ipdatas order by id asc limit 1,10; 31ms
SELECT id FROM ipdatas LIMIT 1,10 ; 0ms
第10000条开始
SELECT id FROM ipdatas ORDER BY id ASC LIMIT ms
select id from ipdatas limit ms
第500万条开始查询
SELECT id FROM ipdatas LIMIT ; 1.750s
SELECT id FROM ipdatas ORDER BY id ASC LIMIT ;14.328s
第6000万条记录开始查询
SELECT id FROM ipdatas LIMIT ; 116.406s
SELECT id FROM ipdatas ORDER BY id ASC LIMIT ; 136.391s
select id from ipdatas limit ; 29.032s
select id from ipdatas limit ; 24.594s
select id from ipdatas limit ; 24.812s
select id from ipdatas limit ; 28.750s
select id from ipdatas limit ; 30.797s
select id from ipdatas limit ; 133.012s
select * from ipdatas limit ; 27.328s
select * from ipdatas limit ; 15.188s
select * from ipdatas limit ; 45.218s
select * from ipdatas limit ; 49.250s
select * from ipdatas limit ; 73.297s
select * from ipdatas limit ; 67.891s
select id from ipdatas order by id asc limit ; 29.438s
select id from ipdatas order by id asc limit ; 24.719s
select id from ipdatas order by id asc limit ; 25.969s
select id from ipdatas order by id asc limit ; 29.860d
select id from ipdatas order by id asc limit ; 32.844s
select id from ipdatas order by id asc limit ; 34.047s
至于SELECT * ipdatas order by id asc 就不测试了 大概都在十几分钟左右
可见通过SELECT id 不带排序的情况下差距不太大,加了排序差距巨大
下面看看这条语句
SELECT * FROM ipdatas WHERE id IN (,,0,00,);
耗时0.094ms
可见in在id上面的查询可以忽略不计毕竟是6000多万条记录，所以为什么很多lucene或solr搜索都返回id进行数据库重新获得数据就是因为这 个,当然lucene/solr+mysql是一个不错的解决办法这个非常适合前端搜索技术,比如前端的分页搜索通过这个可以得到非常好的性能.还可以支 持很好的分组搜索结果集,然后通过id获得数据记录的真实数据来显示效果真的不错,别说是千万级别就是上亿也没有问题,真是吐血推荐啊.
上面的内容还没有进行有条件的查询仅仅是一些关于orderby和limit的测试,请关注我的下一篇文件对于条件查询的1亿数据检索测试
原文地址：
mysql服务性能优化—my.cnf配置说明详解（16G内存）
MYSQL服务器my.cnf配置文档详解
硬件：内存16G
port = 3306
socket = /data/3306/mysql.sock
no-auto-rehash
user = mysql
port = 3306
socket = /data/3306/mysql.sock
basedir = /usr/local/mysql
datadir = /data/3306/data
open_s_limit
back_log = 600
#在MYSQL暂时停止响应新请求之前，短时间内的多少个请求可以被存在堆栈中。如果系统在短时间内有很多连接，则需要增大该参数的值，该参数值指定到来的TCP/IP连接的监听队列的大小。默认值50。
max_connections = 3000
#MySQL允许最大的进程连接数，如果经常出现Too Many Connections的错误提示，则需要增大此值。
max_connect_errors = 6000
#设置每个主机的连接请求异常中断的最大次数，当超过该次数，MYSQL服务器将禁止host的连接请求，直到mysql服务器重启或通过flush hosts清空此host的相关信息。
table_cache = 614
#指示表调整缓冲区大小。# table_cache 参数设置表高速缓存的数目。每个连接进来，都会至少打开一个表缓存。#因此， table_cache 的大小应与 max_connections 的设置有关。例如，对于 200 个#并行运行的连接，应该让表的缓存至少有 200 × N ，这里 N 是应用可以执行的查询#的一个联接中表的最大数量。此外，还需要为临时表和文件保留一些额外的文件描述符。
访问一个表时，如果该表在缓存中已经被打开，则可以直接访问缓存；如果#还没有被缓存，但是在 Mysql 表缓冲区中还有空间，那么这个表就被打开并放入表缓#冲区；如果表缓存满了，则会按照一定的规则将当前未用的表释放，或者临时扩大表缓存来存放，使用表缓存的好处是可以更快速地访问表中的内容。执行 flush tables 会#清空缓存的内容。一般来说，可以通过查看运行峰值时间的状态值 Open_tables #和 Opened_tables ，判断是否需要增加 table_cache 的值（其中 open_tables 是当#前打开的表的数量， Opened_tables 则是已经打开的表的数量）。即如果open_tables接近table_cache的时候，并且Opened_tables这个值在逐步增加，那就要考虑增加这个#值的大小了。还有就是Table_locks_waited比较高的时候，也需要增加table_cache。
external-locking = FALSE
#使用–skip-external-locking MySQL选项以避免外部锁定。该选项默认开启
#设置在网络传输中一次消息传输量的最大值。系统默认值 为1MB，最大值是1GB，必须设置1024的倍数。
sort_buffer_size = 2M
# Sort_Buffer_Size 是一个connection级参数，在每个connection（session）第一次需要使用这个buffer的时候，一次性分配设置的内存。
#Sort_Buffer_Size 并不是越大越好，由于是connection级的参数，过大的设置+高并发可能会耗尽系统内存资源。例如：500个连接将会消耗 500*sort_buffer_size(8M)=4G内存
#Sort_Buffer_Size 超过2KB的时候，就会使用mmap() 而不是 malloc() 来进行内存分配，导致效率降低。
#技术导读 //mysql-sort_buffer_size/
#dev-doc: /doc/refman/5.5/en/server-parameters.html
#explain select*from table where order limit；出现filesort
#属重点优化参数
join_buffer_size = 2M
#用于表间关联缓存的大小，和sort_buffer_size一样，该参数对应的分配内存也是每个连接独享。
thread_cache_size = 300
# 服务器线程缓存这个值表示可以重新利用保存在缓存中线程的数量,当断开连接时如果缓存中还有空间,那么客户端的线程将被放到缓存中,如果线程重新被请求，那么请求将从缓存中读取,如果缓存中是空的或者是新的请求，那么这个线程将被重新创建,如果有很多新的线程，增加这个值可以改善系统性能.通过比较 Connections 和 Threads_created 状态的变量，可以看到这个变量的作用。设置规则如下：1GB 内存配置为8，2GB配置为16，3GB配置为32，4GB或更高内存，可配置更大。
thread_concurrency = 8
# 设置thread_concurrency的值的正确与否, 对mysql的性能影响很大, 在多个u(或多核)的情况下，错误设置了thread_concurrency的值, 会导致mysql不能充分利用多cpu(或多核), 出现同一时刻只能一个cpu(或核)在工作的情况。thread_concurrency应设为CPU核数的2倍. 比如有一个双核的CPU, 那么thread_concurrency的应该为4; 2个双核的cpu, thread_concurrency的值应为8
#属重点优化参数
query_cache_size = 64M
## 对于使用MySQL的用户，对于这个变量大家一定不会陌生。前几年的MyISAM引擎优化中，这个参数也是一个重要的优化参数。但随着发展，这个参数也爆露出来一些问题。机器的内存越来越大，人们也都习惯性的把以前有用的参数分配的值越来越大。这个参数加大后也引发了一系列问题。我们首先分析一下 query_cache_size的工作原理：一个SELECT查询在DB中工作后，DB会把该语句缓存下来，当同样的一个SQL再次来到DB里调用时，DB在该表没发生变化的情况下把结果从缓存中返回给Client。这里有一个关建点，就是DB在利用Query_cache工作时，要求该语句涉及的表在这段时间内没有发生变更。那如果该表在发生变更时，Query_cache里的数据又怎么处理呢？首先要把Query_cache和该表相关的语句全部置为失效，然后在写入更新。那么如果Query_cache非常大，该表的查询结构又比较多，查询语句失效也慢，一个更新或是Insert就会很慢，这样看到的就是Update或是Insert怎么这么慢了。所以在数据库写入量或是更新量也比较大的系统，该参数不适合分配过大。而且在高并发，写入量大的系统，建议把该功能禁掉。
#重点优化参数（主库 增删改-MyISAM）
query_cache_limit = 4M
#指定单个查询能够使用的缓冲区大小，缺省为1M
query_cache_min_res_unit = 2k
#默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易造成内存碎片和浪费
#查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%
#如果查询缓存碎片率超过20%，可以用FLUSH QUERY CACHE整理缓存碎片，或者试试减小query_cache_min_res_unit，如果你的查询都是小数据量的话。
#查询缓存利用率 = (query_cache_size – Qcache_free_memory) / query_cache_size * 100%
#查询缓存利用率在25%以下的话说明query_cache_size设置的过大，可适当减小;查询缓存利用率在80%以上而且Qcache_lowmem_prunes & 50的话说明query_cache_size可能有点小，要不就是碎片太多。
#查询缓存命中率 = (Qcache_hits – Qcache_inserts) / Qcache_hits * 100%
default-storage-engine = MyISAM
#default_table_type = InnoDB
thread_stack = 192K
#设置MYSQL每个线程的堆栈大小，默认值足够大，可满足普通操作。可设置范围为128K至4GB，默认为192KB。
transaction_isolation = READ-COMMITTED
# 设定默认的事务隔离级别.可用的级别如下:
# READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE
# 1.READ UNCOMMITTED-读未提交2.READ COMMITTE-读已提交3.REPEATABLE READ -可重复读4.SERIALIZABLE -串行
tmp_table_size = 256M
# tmp_table_size 的默认大小是 32M。如果一张临时表超出该大小，MySQL产生一个 The table tbl_name is full 形式的错误，如果你做很多高级 GROUP BY 查询，增加 tmp_table_size 值。如果超过该值，则会将临时表写入磁盘。
max_heap_table_size = 256M
long_query_time = 2
log_long_foat
log-slow-queries=/data/3306/slow-log.log
#log-bin = /data/3306/mysql-bin
binlog_cache_size = 4M
max_binlog_cache_size = 8M
max_binlog_size = 512M
expire_logs_days = 7
key_buffer_size = 2048M
#批定用于索引的缓冲区大小，增加它可以得到更好的索引处理性能，对于内存在4GB左右的服务器来说，该参数可设置为256MB或384MB。
read_buffer_size = 1M
# MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySql会为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。如果对表的顺序扫描请求非常频繁，并且你认为频繁扫描进行得太慢，可以通过增加该变量值以及内存缓冲区大小提高其性能。和sort_buffer_size一样，该参数对应的分配内存也是每个连接独享。
read_rnd_buffer_size = 16M
# MySql的随机读（查询操作）缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，将分配一个随机读缓存区。进行排序查询时，MySql会首先扫描一遍该缓冲，以避免磁盘搜索，提高查询速度，如果需要排序大量数据，可适当调高该值。但MySql会为每个客户连接发放该缓冲空间，所以应尽量适当设置该值，以避免内存开销过大。
bulk_insert_buffer_size = 64M
#批量插入数据缓存大小，可以有效提高插入效率，默认为8M
myisam_sort_buffer_size = 128M
# MyISAM表发生变化时重新排序所需的缓冲
myisam_max_sort_file_size = 10G
# MySQL重建索引时所允许的最大临时文件的大小 (当 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE).
# 如果文件大小比此值更大,索引会通过键值缓冲创建(更慢)
myisam_max_extra_sort_file_size = 10G
myisam_repair_threads = 1
# 如果一个表拥有超过一个索引, MyISAM 可以通过并行排序使用超过一个线程去修复他们.
# 这对于拥有多个CPU以及大量内存情况的用户,是一个很好的选择.
myisam_recover
#自动检查和修复没有适当关闭的 MyISAM 表
skip-name-resolve
lower_case_table_names = 1
server-id = 1
innodb_additional_mem_pool_size = 16M
#这个参数用来设置 InnoDB 存储的数据目录信息和其它内部数据结构的内存池大小，类似于Oracle的liby cache。这不是一个强制参数，可以被突破。
innodb_buffer_pool_size = 2048M
# 这对Innodb表来说非常重要。Innodb相比MyISAM表对缓冲更为敏感。MyISAM可以在默认的 key_buffer_size 设置下运行的可以，然而Innodb在默认的 innodb_buffer_pool_size 设置下却跟蜗牛似的。由于Innodb把数据和索引都缓存起来，无需留给操作系统太多的内存，因此如果只需要用Innodb的话则可以设置它高达 70-80% 的可用内存。一些应用于 key_buffer 的规则有 — 如果你的数据量不大，并且不会暴增，那么无需把 innodb_buffer_pool_size 设置的太大了
innodb_data_file_path = ibdata1:1024M:autoextend
#表空间文件 重要数据
innodb_file_io_threads = 4
#文件IO的线程数，一般为 4，但是在 Windows 下，可以设置得较大。
innodb_thread_concurrency = 8
#服务器有几个CPU就设置为几，建议用默认设置，一般为8.
innodb_flush_log_at_trx_commit = 2
# 如果将此参数设置为1，将在每次提交事务后将日志写入磁盘。为提供性能，可以设置为0或2，但要承担在发生故障时丢失数据的风险。设置为0表示事务日志写入日志文件，而日志文件每秒刷新到磁盘一次。设置为2表示事务日志将在提交时写入日志，但日志文件每次刷新到磁盘一次。
innodb_log_buffer_size = 16M
#此参数确定些日志文件所用的内存大小，以M为单位。缓冲区更大能提高性能，但意外的故障将会丢失数据.MySQL开发人员建议设置为1－8M之间
innodb_log_file_size = 128M
#此参数确定数据日志文件的大小，以M为单位，更大的设置可以提高性能，但也会增加恢复故障数据库所需的时间
innodb_log_files_in_group = 3
#为提高性能，MySQL可以以循环方式将日志文件写到多个文件。推荐设置为3M
innodb_max_dirty_pages_pct = 90
#推荐阅读 /html/221_innodb_max_dirty_pages_pct_checkpoint.html
# Buffer_Pool中Dirty_Page所占的数量，直接影响InnoDB的关闭时间。参数innodb_max_dirty_pages_pct 可以直接控制了Dirty_Page在Buffer_Pool中所占的比率，而且幸运的是innodb_max_dirty_pages_pct是可以动态改变的。所以，在关闭InnoDB之前先将innodb_max_dirty_pages_pct调小，强制数据块Flush一段时间，则能够大大缩短 MySQL关闭的时间。
innodb_lock_wait_timeout = 120
# InnoDB 有其内置的死锁检测机制，能导致未完成的事务回滚。但是，如果结合InnoDB使用MyISAM的lock tables 语句或第三方事务引擎,则InnoDB无法识别死锁。为消除这种可能性，可以将innodb_lock_wait_timeout设置为一个整数值，指示 MySQL在允许其他事务修改那些最终受事务回滚的数据之前要等待多长时间(秒数)
innodb_file_per_table = 0
#独享表空间（关闭）
[mysqldump]
max_allowed_packet = 32M
[mysqld_safe]
log-error=/data/3306/mysql_oldboy.err
pid-file=/data/3306/mysqld.pid
#wait_timeout = 10
#指定一个请求的最大连接时间，对于4GB左右的内存服务器来说，可以将其设置为5-10。
#skip_networking
#开启该选可以彻底关闭MYSQL的TCP/IP连接方式，如果器是以远程连接的方式访问MYSQL数据库服务器的，则不要开启该选项，否则将无法正常连接。
#log-queries-not-using-indexes
将没有使用索引的查询也记录下来
转载请注明：
大数据量时Mysql的优化要点
1、对查询进行优化、应尽量避免全表扫描、首先应考虑在 where 及 order by 涉及的列上建立索引。
2、应尽量避免在 where 子句中对字段进行 null 值判断、否则将导致引擎放弃使用索引而进行全表扫描、如：
select id from
–可以在num上设置默认值0、确保表中num列没有null值、然后这样查询：
select id from t where num=0;
3、应尽量避免在 where 子句中使用!=、&&、&=、&=、&、&等操作符、否则将引擎放弃使用索引而进行全表扫描。
4、应尽量避免在 where 子句中使用 or 来连接条件、否则将导致引擎放弃使用索引而进行全表扫描、如：
select id from t where num=10 or num=20
–可以这样查询：
select id from t where num=10
select id from t where num=20;
5、in 和 not in 也要慎用、否则会导致全表扫描、如：
select id from t where num in(1,2,3);
对于连续的数值、能用 between 就不要用 in 了：
select id from t where num between 1 and 3;
6、下面的查询也将导致全表扫描：
select id from t where name like ‘?c%’;
尽量使用select id from t where name like ‘abc%’; 通配符在开始索引不会被使用
–若要提高效率、可以考虑全文检索。
7、如果在 where 子句中使用参数、也会导致全表扫描。因为SQL只有在运行时才会解析局部变量、但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而、如果在编译时建立访问计划、变量的值还是未知的、因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where ;
–可以改为强制查询使用索引：
select id from t with(index(索引名)) where ;
8、应尽量避免在 where 子句中对字段进行表达式操作、这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100;
–应改为:
select id from t where num=100*2;
9、应尽量避免在where子句中对字段进行函数操作、这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)=
–name以abc开头的id
select id from t where datediff(day,createdate,)=0;
–‘’生成的id
–应改为:
select id from t where name like abc%;
select id from t where createdate&= and createdate&;
10、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算、否则系统将可能无法正确使用索引。
11、在使用索引字段作为条件时、如果该索引是复合索引、那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引、否则该索引将不会被使用、并且应尽可能的让字段顺序与索引顺序相一致。
12、不要写一些没有意义的查询、如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0;
–这类代码不会返回任何结果集、但是会消耗系统资源的、应改成这样：
create table #t(…);
13、很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b);
–用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num);
14、并不是所有索引对查询都有效、SQL是根据表中数据来进行查询优化的、当索引列有大量数据重复时、SQL查询可能不会去利用索引、如一表中有字段sex、male、female几乎各一半、那么即使在sex上建了索引也对查询效率起不了作用。
15、索引并不是越多越好、索引固然可以提高相应的 select 的效率、但同时也降低了 insert 及 update 的效率、因为 insert 或 update 时有可能会重建索引、所以怎样建索引需要慎重考虑、视具体情况而定。一个表的索引数最好不要超过6个、若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16、应尽可能的避免更新 clustered 索引数据列、因为 clustered 索引数据列的顺序就是表记录的物理存储顺序、一旦该列值改变将导致整个表记录的顺序的调整、会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列、那么需要考虑是否应将该索引建为 clustered 索引。
17、尽量使用数字型字段、若只含数值信息的字段尽量不要设计为字符型、这会降低查询和连接的性能、并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符、而对于数字型而言只需要比较一次就够了。
18、尽量使用char，char是固定长度的，查询速度比varchar更快，varchar是根据字符长度来使用空间的，所以不定长的字符串能减少存储空间，但查询效率没有char来的快。当字符串长度固定的时候，推荐用char，
19、任何地方都不要使用 select * from t 、用具体的字段列表代替“*”、不要返回用不到的任何字段。
20、尽量使用表变量来代替临时表。如果表变量包含大量数据、请注意索引非常有限（只有主键索引）。
21、避免频繁创建和删除临时表、以减少系统表资源的消耗。
22、临时表并不是不可使用、适当地使用它们可以使某些例程更有效、例如、当需要重复引用大型表或常用表中的某个数据集时。但是、对于一次性事件、最好使用导出表。
23、在新建临时表时、如果一次性插入数据量很大、那么可以使用 select into 代替 create table、避免造成大量 log 、以提高速度；如果数据量不大、为了缓和系统表的资源、应先create table、然后insert。
24、如果使用到了临时表、在存储过程的最后务必将所有的临时表显式删除、先 truncate table 、然后 drop table 、这样可以避免系统表的较长时间锁定。
25、尽量避免使用游标、因为游标的效率较差、如果游标操作的数据超过1万行、那么就应该考虑改写。
26、使用基于游标的方法或临时表方法之前、应先寻找基于集的解决方案来解决问题、基于集的方法通常更有效。
27、与临时表一样、游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法、尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许、基于游标的方法和基于集的方法都可以尝试一下、看哪一种方法的效果更好。
28、在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON 、在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
29、尽量避免大事务操作、提高系统并发能力。
30、尽量避免向客户端返回大数据量、若数据量过大、应该考虑相应需求是否合理。