1. 如何解决sql查询速度太慢
解决方法如下：
1、把数据、日志、索引放到不同的设备上，增加读取速度；
2、纵向、横向分割表，减少表的尺寸；
3、升级硬件；
4、困烂根据查询条件,建立索引，优化索引、优化闷厅访问方式，限制结果集的数据量，注意填充因子要适当，索引应该尽量小，使用字节数小的列建索引蚂尺隐好，不要对有限的几个值的字段建单一索引如性别字段；
4、提高网速。
2. 更改SQL Server 2012 数据库排序规则
针对市面上有部份应用系统或者ERP系统对于数据库的排序规则是有要求，若安装数据库时没有留意，采用默认安装后，导致应用打开出现异常或者乱码现象。其实不用再卸载重装，通过如下步骤进行更改，节省大量的时间：
1、先停止需要变更 sqlserver 的服务 : 在 运行命令行中 services.msc 命令，在打开的服界面打到并关闭sql server 的服务；（直接通过 Net stop mssqlserver 语句也可以关闭SQL Server 后台服务）
2、执行命令：（cmd命令行）
F:>Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=administrator /SAPWD=****** /SQLCOLLATION=Chinese_PRC_BIN
参数介绍：
InstanceName : MSSQLSERVER 默认为：MSSQLSERVER
SQLSYSADMINACCOUNTS: administrator 默认为：administrator
StrongPassword : sa账号的密码
CollationName : Chinese_PRC_BIN （根据实际情况需要填写）
F:>setup为安装文件存放路径；
3、等几分钟。出现成功提示
4、执行命令 Net start mssqlserver 启动 SqlServer
5、原有各个数据库会被移出，需要手动进行“附加数据库”数据库操作
3. 如何解决SQL查询速度太慢
1. 执行计划中明明有使用到索引，为什么执行还是这么慢？
2. 执行计划中显示扫描行数为 644，为什么 slow log 中显示 100 多万行？
a. 我们先看执行计划，选择的索引 “INDX_BIOM_ELOCK_TASK3(TASK_ID)”。结合 sql 来看，因为有 "ORDER BY TASK_ID DESC" 子句，排序通常很慢，如果使用了文件排序性能会更差，优化器选择这个索引避免了排序。
那为什么不选 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很简单，TASK_DATE 字段区分度太低了，走这个索引需要扫描的行数很大，而且还要进行额外的排序，优化器综合判断代价更大，所以就不选这个索引了。不过如果我们强制选择这个索引（用 force index 语法），会看到 SQL 执行速度更快少于 10s，那是因为优化器基于代价的原则并不等价于执行速度的快慢；
b. 再看执行计划中的 type:index，"index" 代表 “全索引扫描”，其实和全表扫描差不多，只是扫描的时候是按照索引次序进行而不是行，主要优点就是避免了排序，但是开销仍然非常大。
Extra:Using where 也意味着扫描完索引后还需要回表进行筛选。一般来说，得保证 type 至少达到 range 级别，最好能达到 ref。
在第 2 点中提到的“慢日志记录Rows_examined: 1161559，看起来是全表扫描”，这里更正为“全索引扫描”，扫描行数确实等于表的行数；
c. 关于执行计划中：“rows：644”，其实这个只是估算值，并不准确，我们分析慢 SQL 时判断准确的扫描行数应该以 slow log 中的 Rows_examined 为准。
4. 优化建议：添加组合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)
优化过程：
TASK_DATE 字段存在索引，但是选择度很低，优化器不会走这个索引，建议后续可以删除这个索引：
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+
在这个 sql 中 REL_DEVID 字段从命名上看选择度较高，通过下面 sql 来检验确实如此：
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+
由于有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 组合选择度 100%：
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+
在测试环境添加 REL_DEVID，TASK_ID 组合索引，测试 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引后执行计划：
这里还要注意一点“隐式转换”：REL_DEVID 字段数据类型为 varchar，需要在 sql 中加引号：AND T.REL_DEVID = 000000025xxx >> AND T.REL_DEVID = '000000025xxx'
执行时间从 10s+ 降到 毫秒级别：
1 row in set (0.00 sec)
结论
一个典型的 order by 查询的优化，添加更合适的索引可以避免性能问题：执行计划使用索引并不意味着就能执行快。
4. sql ORDER BY 多个字段，排序变慢几十倍，求解
SQL 中使用order By后，查询慢，加上主键 和 需要排序的字段组合排序 速度有很大的提升
在SQL Server查询数据测试，数据约三万条， 数据字段以时间倒序排序，
sql:
select ID, column1,column2,column3,record_date from table where ...... order by record_date desc
此时查询数据需要15秒左中 ，将orderby 修改为 order by ID desc,record_date desc 后，查询的数据一秒不到即可查询出来
在linq中，排序的时候，一定要用new 排序的对象，不然ID 将不会被加入到SQL中
linq:
var t = from a in t where ......select a;
t = t.orderby(t=>t.ID).orderby(t=>t.record_date) 此处的ID在解释成SQL时，不会在SQL中
应写为：
t = t.orderby(t=>new{t.ID,t.record_date})