2019-2-20数据库的迁移及聚集、非聚集索引
聚集索引与非聚集索引的总结
一.索引简介
众所周知，索引是关系型数据库中给数据库表中一列或多列的值排序后的存储结构，SQL的主流索引结构有B+树以及Hash结构，聚集索引以及非聚集索引用的是B+树索引。这篇文章会总结SQL Server以及MySQL的InnoDB和MyISAM两种SQL的索引。
SQL Sever索引类型有：唯一索引，主键索引，聚集索引，非聚集索引。
MySQL 索引类型有：唯一索引，主键（聚集）索引，非聚集索引，全文索引。
二.聚集索引
聚集（clustered）索引，也叫聚簇索引。
定义：数据行的物理顺序与列值（一般是主键的那一列）的逻辑顺序相同，一个表中只能拥有一个聚集索引。
单单从定义来看是不是显得有点抽象，打个比方，一个表就像是我们以前用的新华字典，聚集索引就像是拼音目录，而每个字存放的页码就是我们的数据物理地址，我们如果要查询一个“哇”字，我们只需要查询“哇”字对应在新华字典拼音目录对应的页码，就可以查询到对应的“哇”字所在的位置，而拼音目录对应的A-Z的字顺序，和新华字典实际存储的字的顺序A-Z也是一样的，如果我们中文新出了一个字，拼音开头第一个是B，那么他插入的时候也要按照拼音目录顺序插入到A字的后面，现在用一个简单的示意图来大概说明一下在数据库中的样子：
| 地址 | id | username | score |
|---|---|---|---|
| 0x01 | 1 | 小明 | 90 |
| 0x02 | 2 | 小红 | 80 |
| 0x03 | 3 | 小华 | 92 |
| .. | .. | .. | .. |
| 0xff | 256 | 小英 | 70 |
注：第一列的地址表示该行数据在磁盘中的物理地址，后面三列才是我们SQL里面用的表里的列，其中id是主键，建立了聚集索引。
结合上面的表格就可以理解这句话了吧：数据行的物理顺序与列值的顺序相同，如果我们查询id比较靠后的数据，那么这行数据的地址在磁盘中的物理地址也会比较靠后。而且由于物理排列方式与聚集索引的顺序相同，所以也就只能建立一个聚集索引了。
聚集索引实际存放的示意图
从上图可以看出聚集索引的好处了，索引的叶子节点就是对应的数据节点（MySQL的MyISAM除外，此存储引擎的聚集索引和非聚集索引只多了个唯一约束，其他没什么区别），可以直接获取到对应的全部列的数据，而非聚集索引在索引没有覆盖到对应的列的时候需要进行二次查询，后面会详细讲。因此在查询方面，聚集索引的速度往往会更占优势。
创建聚集索引
如果不创建索引，系统会自动创建一个隐含列作为表的聚集索引。
1.创建表的时候指定主键（注意：SQL Sever默认主键为聚集索引，也可以指定为非聚集索引，而MySQL里主键就是聚集索引）
create table t1(
id int primary key,
name nvarchar(255)
)2.创建表后添加聚集索引
SQL Server
create clustered index clustered_index on table_name(colum_name)MySQL
alter table table_name add primary key(colum_name)值得注意的是，最好还是在创建表的时候添加聚集索引，由于聚集索引的物理顺序上的特殊性，因此如果再在上面创建索引的时候会根据索引列的排序移动全部数据行上面的顺序，会非常地耗费时间以及性能。
三.非聚集索引
非聚集（unclustered）索引。
定义：该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同，一个表中可以拥有多个非聚集索引。
其实按照定义，除了聚集索引以外的索引都是非聚集索引，只是人们想细分一下非聚集索引，分成普通索引，唯一索引，全文索引。如果非要把非聚集索引类比成现实生活中的东西，那么非聚集索引就像新华字典的偏旁字典，他结构顺序与实际存放顺序不一定一致。
非聚集索引实际存放的示意图
非聚集索引的二次查询问题
非聚集索引叶节点仍然是索引节点，只是有一个指针指向对应的数据块，此如果使用非聚集索引查询，而查询列中包含了其他该索引没有覆盖的列，那么他还要进行第二次的查询，查询节点上对应的数据行的数据。
如有以下表t1：
| id | username | score |
|---|---|---|
| 1 | 小明 | 90 |
| 2 | 小红 | 80 |
| 3 | 小华 | 92 |
| .. | .. | .. |
| 256 | 小英 | 70 |
以及聚集索引clustered index(id), 非聚集索引index(username)。
使用以下语句进行查询，不需要进行二次查询，直接就可以从非聚集索引的节点里面就可以获取到查询列的数据。
select id, username from t1 where username = '小明'
select username from t1 where username = '小明'但是使用以下语句进行查询，就需要二次的查询去获取原数据行的score：
select username, score from t1 where username = '小明'在SQL Server里面查询效率如下所示，Index Seek就是索引所花费的时间，Key Lookup就是二次查询所花费的时间。可以看的出二次查询所花费的查询开销占比很大，达到50%。
在SQL Server里面会对查询自动优化，选择适合的索引，因此如果在数据量不大的情况下，SQL Server很有可能不会使用非聚集索引进行查询，而是使用聚集索引进行查询，即便需要扫描整个聚集索引，效率也比使用非聚集索引效率要高。
本人试过在含有30w行表上建立非聚集索引，查询非聚集索引覆盖以外的列就会变成聚集索引的全索引扫描（index scan）查询来避免二次查询，而在另外一张200w行表才会用到非聚集索引seek对应的列再进行kek lookup，有关于SQL Server的有Index seek，index scan, table scan，key LookUp这几个概念，可以查看这个blog，描写比较详细。
但在MySQL里面就算表里数据量少且查询了非键列，也不会使用聚集索引去全索引扫描，但如果强制使用聚集索引去查询，性能反而比非聚集索引查询要差，这就是两种SQL的不同之处。
还有一点要注意的是非聚集索引其实叶子节点除了会存储索引覆盖列的数据，也会存放聚集索引所覆盖的列数据。
如何解决非聚集索引的二次查询问题
复合索引（覆盖索引）
建立两列以上的索引，即可查询复合索引里的列的数据而不需要进行回表二次查询，如index(col1, col2)，执行下面的语句
select col1, col2 from t1 where col1 = '213';要注意使用复合索引需要满足最左侧索引的原则，也就是查询的时候如果where条件里面没有最左边的一到多列，索引就不会起作用。
在SQL Server中还有include的用法，可以把非聚集索引里包含的列包含进来，而不一定需要建立复合索引。
四.总结与使用心得
- 使用聚集索引的查询效率要比非聚集索引的效率要高，但是如果需要频繁去改变聚集索引的值，写入性能并不高，因为需要移动对应数据的物理位置。
- 非聚集索引在查询的时候可以的话就避免二次查询，这样性能会大幅提升。
- 不是所有的表都适合建立索引，只有数据量大表才适合建立索引，且建立在选择性高的列上面性能会更好。
程序员过关斩将--数据库快速迁移10亿级数据
问题分析
经过几分钟的排查，数据库情况如下：
至于业务，不是太复杂。经过相关人员咨询，大约40%的请求为单条Insert，大约60%的请求为按class_id 和in_time（倒序）分页获取数据。Select请求全部命中聚集索引，所以性能非常高。这也是聚集索引之所以这样设计的目的。
解决问题
由于单表数据量已经超过21亿，并且2017年以前的数据几乎不影响业务，所以决定把2017年以前（不包括2017年）的数据迁移到新表，仅供以后特殊业务查询使用。经过查询大约有9亿数据量。
数据迁移工作包括三个个步骤：
1. 从源数据表查询出要迁移的数据
2. 把数据插入新表
3. 把旧表的数据删除
传统做法
这里申明一点，就算是传统的做法也需要分页获取源数据，因为你的内存一次性装载不下9亿条数据。
SQL语句类似于
SELECT * FROM (
SELECT *,ROW_NUMBER() OVER(ORDER BY class_id,in_time) p FROM tablexx WHERE in_time <'2017.1.1'
) t WHERE t.p BETWEEN 1 AND 100
如果你的数据量不大，以上方法完全没有问题，但是在9亿这个数字前面，以上方法显得心有余而力不足。一个字：慢，太慢，非常慢。
可以大体算一下，假如每秒可以迁移1000条数据，大约需要的时间为(单位：分)
900000000/1000/60=15000(分钟)
大约需要10天^ V ^
改进做法
以上的传统做法弊端在哪里呢？
1. 在9亿数据前查询必须命中索引，就算是非聚集索引菜菜也不推荐，首推聚集索引。
2. 如果你了解索引的原理，你应该明白，不停的插入新数据的时候，索引在不停的更新，调整，以保持树的平衡等特性。尤其是聚集索引影响甚大，因为还需要移动实际的数据。
提取以上两点共同的要素，那就是聚集索引。相应的解决方案也就应运而生：
1. 按照聚集索分页引查询数据
2. 批量插入数据迎合聚集索引，即：按照聚集索引的顺序批量插入。
3. 按照聚集索引顺序批量删除
由于做了表分区，如果有一种方式把2017年以前的分区直接在磁盘物理层面从当前表剥离，然后挂载到另外一个表，可算是神级操作。有谁能指导一下菜菜，感激不尽
扩展阅读
NetCore 代码(实际运行代码)
1. 第一步：由于聚集索引需要class_id ，所以宁可花2-4秒时间把要操作的class_id查询出来(ORM为dapper)，并且升序排列
DateTime dtMax = DateTime.Parse("2017.1.1");
var allClassId = DBProxy.GeSourcetLstClassId(dtMax)?.OrderBy(s=>s);2. 按照第一步class_id 列表顺序查询数据，每个class_id 分页获取，然后插入目标表，全部完成然后删除源表相应class_id的数据。(全部命中聚集索引)
D int pageIndex = 1; //页码
int pageCount = 20000;//每页的数据条数
DataTable tempData =null;
int successCount = 0;
foreach (var classId in allClassId)
{
tempData = null;
pageIndex = 1;
while (true)
{
int startIndex = (pageIndex - 1) * pageCount+1;
int endIndex = pageIndex * pageCount;
tempData = DBProxy.GetSourceDataByClassIdTable(dtMax, classId, startIndex, endIndex);
if (tempData == null || tempData.Rows.Count==0)
{
//最后一页无数据了，删除源数据源数据然后跳出
DBProxy.DeleteSourceClassData(dtMax, classId);
break;
}
else
{
DBProxy.AddTargetData(tempData);
}
pageIndex++;
}
successCount++;
Console.WriteLine($"班级:{classId} 完成,已经完成：{successCount}个");
}
DBProxy 完整代码：
class DBProxy
{
//获取要迁移的数据所有班级id
public static IEnumerable<int> GeSourcetLstClassId(DateTime dtMax)
{
var connection = Config.GetConnection(Config.SourceDBStr);
string Sql = @"SELECT class_id FROM tablexx WHERE in_time <@dtMax GROUP BY class_id ";
using (connection)
{
return connection.Query<int>(Sql, new { dtMax = dtMax }, commandType: System.Data.CommandType.Text);
}
}
public static DataTable GetSourceDataByClassIdTable(DateTime dtMax, int classId, int startIndex, int endIndex)
{
var connection = Config.GetConnection(Config.SourceDBStr);
string Sql = @" SELECT * FROM (
SELECT *,ROW_NUMBER() OVER(ORDER BY in_time desc) p FROM tablexx WHERE in_time <@dtMax AND class_id=@classId
) t WHERE t.p BETWEEN @startIndex AND @endIndex ";
using (connection)
{
DataTable table = new DataTable("MyTable");
var reader = connection.ExecuteReader(Sql, new { dtMax = dtMax, classId = classId, startIndex = startIndex, endIndex = endIndex }, commandType: System.Data.CommandType.Text);
table.Load(reader);
reader.Dispose();
return table;
}
}
public static int DeleteSourceClassData(DateTime dtMax, int classId)
{
var connection = Config.GetConnection(Config.SourceDBStr);
string Sql = @" delete from tablexx WHERE in_time <@dtMax AND class_id=@classId ";
using (connection)
{
return connection.Execute(Sql, new { dtMax = dtMax, classId = classId }, commandType: System.Data.CommandType.Text);
}
}
//SqlBulkCopy 批量添加数据
public static int AddTargetData(DataTable data)
{
var connection = Config.GetConnection(Config.TargetDBStr);
using (var sbc = new SqlBulkCopy(connection))
{
sbc.DestinationTableName = "tablexx_2017";
sbc.ColumnMappings.Add("class_id", "class_id");
sbc.ColumnMappings.Add("in_time", "in_time");
.
.
.
using (connection)
{
connection.Open();
sbc.WriteToServer(data);
}
}
return 1;
}
}运行报告:
程序本机运行，开vpn连接远程DB服务器，运行1分钟，迁移的数据数据量为 1915560，每秒约3万条数据
1915560 / 60=31926 条/秒
cpu情况（不高）：
磁盘队列情况（不高）：
写在最后
在以下情况下速度还将提高
1. 源数据库和目标数据库硬盘为ssd，并且分别为不同的服务器
2. 迁移程序和数据库在同一个局域网，保障数据传输时候带宽不会成为瓶颈
3. 合理的设置SqlBulkCopy参数
4. 菜菜的场景大多数场景下每次批量插入的数据量达不到设置的值，因为有的class_id 对应的数据量就几十条，甚至几条而已，打开关闭数据库连接也是需要耗时的
5. 单纯的批量添加或者批量删除操作
