CDC 变更数据捕获技术的问题及局限

现在的cdc功能仍然还是会让你失望的。 
优点就不说了，就是联机丛书里面写的那些。
缺点如下：
1、目前为止cdc无法与日志文件关联，更多有用的信息，仍需要进行前后数据比对获取。（一般仍会使用触发器进行替代记录）
2、目前为止cdc可以记录DDl的相关处理，但是更多的信息，如记录IP等用户信息仍然需要另外的代码支持。


select * into PT_CUSTOMER_INFO_BAK from PT_CUSTOMER_INFO

类似oracle的create table as select * from t;

约束也不会带过来。


alt + q
看sql server的执行计划。


聚集索引表：和oracle的iot表，索引表是一样的概念，表和索引是在一起的，即：表就是排序的。

非聚集索引表：就是堆表

执行计划：

1. 【Table Scan】：遍历整个表，查找所匹配的记录行。这个操作将会一行一行的检查，当然，效率也是最差的。

2. 【Index Scan】：根据索引，从表中过滤出来一部分记录，再查找所匹配的记录行，显示比第一种方式的查找范围要小，因此比【Table Scan】要快。

3. 【Index Seek】：根据索引，定位（获取）记录的存放位置，然后取得记录，因此，比起前二种方式会更快。

4. 【Clustered Index Scan】：和【Table Scan】一样。注意：不要以为这里有个Index，就认为不一样了。

    其实它的意思是说：按聚集索引来逐行扫描每一行记录，因为记录就是按聚集索引来顺序存放的。
    
    而【Table Scan】只是说：要扫描的表没有聚集索引而已，因此这二个操作本质上也是一样的。

5. 【Clustered Index Seek】：直接根据聚集索引获取记录，最快！


还有一个小问题，删除索引 和 删除主键的方式不同，因为主键属于约束，不是索引。

删除索引：drop index IDX_PROVINCE_ID on PT_CUSTOMER_INFO_BAK

删除主键：alter table PT_CUSTOMER_INFO_BAK drop constraint PK_PT_CUSTOMER_INFO_BAK

添加主键：

ALTER TABLE PT_CUSTOMER_INFO_BAK
ADD CONSTRAINT PK_PT_CUSTOMER_INFO_BAK PRIMARY KEY nonclustered(ID);
go