各位亲爱的云友，
zc_0101（Q1）：请问大神石沫：如何判断MSSQL数据库磁盘出现了瓶颈？
石沫（A1）：您好，您的问题非常好，SQL SERVER提供了很多关于I/O压力的性能计数器，请选择性能计算器PhysicalDisk（LogicalDisk），根据我们的经验，如下指标的阈值可以帮助你判断IO是否存在压力：
1.
2.
3.
4.
5.
6.
7.
以上，请根据自己的磁盘系统判断，比如传统的机械臂磁盘和SSD有所不同。
一般磁盘的优化方向是：
1. 硬件优化：比如使用更合理的RAID阵列，使用更快的磁盘驱动器，添加更多的内存
2. 数据库设置优化：比如创建多个文件和文件组，表的INDEX和数据放到不同的DISK上，将数据库的日志放到单独的物理驱动器，使用分区表
3. 数据库应用优化：包括应用程序的设计，SQL语句的调整，表的设计的合理性，INDEX创建的合理性，涉及的范围很广
希望对您有所帮助，谢谢！
鹰舞（Q2）：MSSQL 2012的alwayson技术已经在线上使用了，但是发现在辅助副本上经常会出现AG延迟的情况，检查是因为辅助副本中的业务长时间查询导致了AG进程的还原block，锁是意向架构锁，请问下这个是什么原因导致呢？有什么办法可以避免此问题？
石沫（A2）：您好，根据您的描述，由于查询产生了副本REDO LOG延迟，出现了架构锁。我们知道SQL SERVER 2012 AlwaysOn在某些数据库行为上有较多变化。我们先看看架构锁：
架构锁分成两类：
1. SCH-M：架构更改锁，主要发生在数据库SCHEMA的修改上，从你的描述看，没有更改SCHEMA，那么可以排除这个因素
2. SCH-S：架构稳定锁，主要发生在数据库的查询编译等活动
根据你的情况，应该属于SCH-S导致的。查询编译活动主要发生有新增加了INDEX, 更新了统计信息，未参数化的SQL语句等等
对于INDEX和SQL语句方面应，我想应该不会有太多问题。
我们重点关注一下统计信息：SQL SERVER 2012 AG副本的统计信息维护有两种：
1. 主体下发到副本
2. 临时统计信息存储在TEMPDB
对于主体下发的，我们可以设置统计信息的更新行为，自动更新时，可以设置为异步的（自动更新统计信息必须首先打开）：
USE [master]
GO
ALTER DATABASE [Test_01]
WITH NO_WAIT
GO
这样的话查询优化器不等待统计信息更新完成即编译查询。可以优化一下你的BLOCK。
对于临时统计信息存储在TEMPDB里面也是很重要的，再加上ALWAYSON的副本数据库默认是快照隔离，优化TEMPDB也是必要的，关于优化TEPDB这个我想大部分都知道，这里只是提醒一下。
除了从统计信息本身来解决，在查询过程中，可以降低查询的时间，以尽量减少LOCK的时间和范围，这需要优化你的SQL语句或者应用程序。
以上，希望对您有所帮助。谢谢！
leamonjxl（Q3）：目前有一个表，主键为ID自增，数据量很小，更新的并发也不是特别高，Update的条件是表中的另外两个联合字段，但是经常会出现死锁情况，请问是否只有通过修改聚集索引的方式来处理呀，非常感谢。
石沫（A3）：这是一个关于死锁的问题，为了能够提供帮助一些。请根据下列建议进行：
1.
2.
3.
关于跟踪死锁，我们首先需要打开1222标记，例如DBCC TRACEON(1222,-1), 他将收集的信息写入到死锁事件发生的服务器上的日志文件中。同时建议打开Profiler的跟踪信息：
如果发生了死锁，需要分析死锁发生的根源在哪里？我们不是很清楚你的具体发生死锁的形态是怎么样的。
关于死锁的实例也多，这里不再举例。
这里只是提出一些可以解决的思路：
1.
2.
3.
减少锁的争用，可以从几个方面入手
1.
2.
减少资源的访问数，可以从如下几个方面入手：
1.
2.
按照相同的时间顺序访问资源：
确保每个事务按照相同的物理顺序访问资源。两个事务按照相同的物理顺序访问，第一个事务会获得资源上的锁而不会被第二个事务阻塞。第二个事务想获得第一个事务上的LOCK，但被第一个事务阻塞。这样的话就不会导致循环阻塞的情况。
leamonjxl（Q4）：一个数据量超过10亿的表，大神是建议物理分表+视图，还是分区表，这两者性能差距很大么，谢谢。
石沫（A4）：两种方式看你的业务怎么应用。这里不仅是分表的问题，还可能存在分库，分服务器的问题。取决与你的架构方案。
物理分表+视图，这是一种典型的冷热数据分离的方案，大致的做法如下：
1.
2.
分表后，涉及到几个问题：
第一问题是，转移数据的过程，一般是晚上业务比较闲来转移，转移按照一定的规则来做，始终保持3个月，这个定时任务本身也很消耗时间
再者，关于查询部分，我想你们的数据库服务器应该通过REPLICATION做了读写分离的吧，主库我觉得压力不会太大，主要是插入或者更新，只读需要做视图来包含全部的数据，但通过UNION ALL所有分表的数据，最后可能还是非常大，在某些情况下，性能不一定好。这个是不是业务上可以解决。比如，对于1年前的历史数据，放在单独的只读上，相对热的数据放在一起，这样压力也会减少。
分区表的话，因为涉及到10亿数据，要有好的分区方案，相对比较简单一点。但对于10亿的大表，始终是个棘手的问题，无论分多少个分区，单个服务器的资源也是有限的。可扩展性方面也存在问题，比如在只读上你没有办法做服务器级别的拆分了。这可能也会造成瓶颈。
现在很多企业都在做分库分表，这些的要解决一些高并发，数据量大的问题。不知是否考虑过类似于中间件的方案，比如阿里巴巴的TDDL类似的方案，如果你有兴趣，可以查询相关资料。
jiangnii（Q5）：请教石沫大神，MSSQL云数据库的运维和优化，与在普通服务器上的优化是否有某些区别，在云数据库上处理大数据量或复杂的数据操作时有没有什么需要特别注意的地方？ 希望听听您的经验，谢谢！
石沫（A5）：阿里云数据库不仅提供一个数据库，还提供数据库一种服务。阿里云数据库不仅简化了基础架构的部署，还提供了数据库高可用性架构，备份服务，性能诊断服务，监控服务，专家服务等等，保证用户放心、方便、省心地使用数据库，就像水电一样。以前的运维繁琐的事，全部由阿里云接管，用户只需要关注数据库的使用和具体的业务就好。
关于优化和在云数据库上处理大数据量或复杂的数据操作方面，在云数据库上是一样的，没有什么特别的地方，不过我们的云数据库是使用SSD磁盘，这个比普通的磁盘要快很多，IO上有很大的优势。目前单个实例支持1T的数据量大小。陆续我们会推出更多的服务，比如索引诊断，连接诊断，容量分析，空间诊断等等，这些工作可能是专业的DBA才能完成的，以后我们会提供自动化的服务来为客户创造价值，希望能帮助到客户。 谢谢！
daniellin17（Q6）：有个问题想请教大神石沫：有时候碰到 使用ssms和程序连接到实例，运行同一个proc， 结果时间,io开销有明显的差距，执行计划也不一样。请帮忙分析一下原因，以及是否有什么解决办法。
石沫（A6）：这个过程确实有遇到过，定位原因有多种可能。不过我们分析下面几个方向入手：
1.
2.
3.
4.
执行计划缓冲，你可以观察到你的语句到底使用了那个查询计划：
SELECT
FROM sys.dm_exec_cached_plans cp
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st
WHERE st.text LIKE '%********%'
对比你的两种查询计划，如果你确定哪种查询计划不是需要，但又被命中了，可以考虑将不需要的删除掉（但需要慎重），例如：
DBCC FREEPROCCACHE (0x060002007FEA040740C17E
查看你的统计信息情况，你可以。你可以看看你的统计信息是否失效，是否过时，同时更新统计信息使用FULLSAN扫描表或索引视图中的所有行来计算统计信息。同时查看一下相关执行计划变化对象的列的统计分布：
DBCC SHOW_STATITICS(***)
关于你的两种环境执行计划不一样，你提供的参数是否一致，有个参数嗅探的问题，不同的参数可能产生不一样的执行计划，有些执行计划是良好的，有些是给性能造成危害的。这个也需要关注一下，若确定是这个问题，解决这个的办法也很多，比如执行时加WITH RECOMMPILE。,还比如指定查询提示OPTIMIZE FOR等等。另外，你可以将输入参数赋予本地参数，强制优化器查看所引用的数据的统计来对可能使用的值做出好的评估。
存储过程重编译也是一种可能,大致原因有如下,可排查一下，不过根据你的描述应该不是这些原因，只是一个方向:
1.
2.
3.
4.
5.
另外，你可以分析你的语句和变化的执行计划，创建一个更合理的INDEX可能会解决你的问题。同时，你也可以强制指定INDEX,使用WITH (FORCESEEK),不要使用WITH (INDEX=***)
daniellin17（Q7）：你好石沫大神： 还有一个问题，能否根据你多年的经验 谈谈如何增大并行度。 比如说从db的设计层面，还有物理设备，参数配置等等....
石沫（A7）：这个问题我不知道是否是两个问题，一个是并行度，另一个是并发，我更多理解是吞吐量，单就并行度而言。
提高并行度需要考虑的因素有：
1.
2.
3.
4.
5.
6.
7.
以DOP的参数控制并行度为例，设置如下：
SELECT *
FROM sys.configurations WITH (NOLOCK)
WHERE name = 'max degree of parallelism'
EXEC sp_configure 'max degree of parallelism',2
RECONFIGURE WITH OVERRIDE
经过测试，DOP设置为2是一个比较适中的状态，特别是OLTP应用。如果设置高了，会产生较多的SUSPEND进程。我们可以观察到资源等待资源类型是：CXPACKET
你可以用下列语句去测试：
DBCC SQLPERF('sys.dm_os_wait_stats',CLEAR)
SELECT *
FROM sys.dm_os_wait_stats WITH (NOLOCK)
ORDER BY 2 DESC ,3 DESC
如果是吞吐量的话。优化的范围就很广了。优化是系统性的。硬件配置我们选择的话，大多根据业务量来预估，然后考虑以下：
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
我这里列举一个高并发的场景：
比如，我们的订单，比如搞活动的时候，订单刷刷刷地增长，单个实例可能每秒达到很高很高，我们分析到最后最常见的问题是HOT PAGE问题，其等待类型是PAGE LATCH竞争。这个过程可以这么来处理，简单列几点，可以参考很多涉及高并发的案例：
1.
2.
3.
4.
5.
这个场景只是针对高并发的插入。对于查询而言，是不适合的。但这些也可能导致大量的页拆分。只是在不同的场景有不同的设计思路。这里抛砖引玉。
zuijh（Q8）：ECS
石沫（A8）：ECS上现在有两种磁盘，一种是传统的机械臂磁盘，另一种是SSD，请先诊断你的IO是否出现了问题，本帖中有提到如何判断磁盘出现问题的相关话题，请参考。如果确定IO出现问题，可以尝试使用ECS LOCAL SSD。当然，我们欢迎你使用云数据库的产品，云数据库提供了很多有用的功能，比如高可用性，灵活的备份方案，灵活的弹性方案，实用的监控报警等等。
豪杰本疯子（Q9）：请教大神石沫，mssql数据到后期数据库越大，查询越频繁，可以通过什么硬件和技术来处理后期效率和安全的问题？
石沫（A9）：我们单个主机或者单个实例的资源总是有限的，因为涉及到很大的数据量，对于存储而言是个瓶颈，我曾使用过SAN和SAS存储，SAN存储的优势确实可以解决数据的灵活扩展，但是SAN也分IPSAN和FIBER SAN，如果IPSAN的话，性能会差一些。即使是FIBER SAN，也不是很好解决性能问题，这不是它的优势，同时，我们所有DB SERVER都连接到SAN上，如果SAN有问题，问题涉及的面就很广。但是SAS毕竟空间也是有限的。最终也会到瓶颈。数据量大，是造成性能问题的直接原因，因为我们不管怎么优化，一旦数据量太大，优化的能力总是有限的，所以这个时候更多从架构上考虑。单个主机单个实例肯定是抗不过来的。
所以现在很多企业在向分布式系统发展，对于数据库而言，其实有很多形式。我们最常见的是读写分离，比如SQL SERVER而言，我们可以通过复制来完成读写分离，SQL SERVER 2012及以后的版本，我们可以使用ALWAYSON来实现读写分离，但这只能解决性能问题，那空间问题怎么解决。我们就涉及到分库分表，这个分库分表跟应用结合得紧密，现在很多公司通过中间件来实现，比如TDDL。但是中间件不是每个公司都可以玩得转的。因此可以将业务垂直拆分，那么DB也可以由此拆分开来。举个简单例子，我们一个典型的电子商务系统，有订单，有促销，有仓库，有配送，有财务，有秒杀，有商品等等，很多公司在初期，都是将这些放在一个主机一个实例上。但是这些到了一定规模或者一定数据量后，就会出现性能和硬件资源问题，这时我们可以将它们独立一部分获完全独立出来。这些都是一些好的方向。希望对你有所帮助。
dt（Q10）：求大数据量下mysql存储，优化方案 ，分区好还是分表好，分的过程中需要考虑事项，mysql高并发读写的一些解决办法
石沫（A10）：分区：对于应用来说比较简单,改造较少
分表: 应用需较多改造，优点是数据量太大的情况下，分表可以拆分到多个实例上，而分区不可以。
高并发优化,有两个建议:
1.
2.
http://www.open-open.com/doc/view/d58cadb4fb68429587634a77
aelven（Q11）：请问大神石沫：
1.MSSQL2008 适合用于大型网站大并发大访问量的像携程网这类的酒店预订网站吗(例如连接数量比较大,频繁更新酒店价格)
2.连接数比较大更新频率比较高 比如像1个表里存储着100条酒店数据每条数据有1个列是价格,这个类更新的频率很高,我的是asp.net程序用存储过程会更好吗?
3.自己用阿里云搭建的数据服务器和 用阿里云的rds mssql相比起来会差别很大吗? 阿里云的mssql是不是有比较好的安全防护,和基本的优化?
石沫（A11）：对于第一个问题.需要看看你的数据库架构是什么样的?比如你的架构具有高可用行?具有读写分离的架构?具有群集的架构.数据库应用是否有较冷门的功能。高并发应该不是什么问题。可扩展性方面需要考虑。阿里云数据库提供了很多优势，比如磁盘是性能超好的SSD，自动转移的高可用性，没有任何单点，自动灵活的备份方案，实用的监控报警，性能监控服务等等，省去DBA很多基础性工作。
你第二个问题，看起来是一个高并发的场景，这种高并发的场景容易出现大量的LOCK甚至死锁，我不是很清楚你的业务，但可以建议一下，首先可以考虑快照隔离级别，实现行多版本控制，让读写不要阻塞。至于写写过程，需要加锁的粒度降低最低，同时这种高并发也容易出现死锁，关于死锁的分析，本帖有提到，请关注。
第三个问题，你用ECS搭建自己的应用也是可以的，RDS数据库提供了很多功能，上面已经讲到了。安全问题一直是我们最看重的问题，肯定有超好的防护的。
cherish_j（Q12）：作为从业多年的DBA角度考虑，MSSQL Server哪些方面还需要加以改进，或者说目前的产品瓶颈在哪里？
石沫（A12）：哈哈，这是跟MS拉仇恨不是，不过我们尝试给他们提供一些建议。就我而言，也可能是大家关心的几个问题：
1.
2.
3.
板砖大叔（Q13）：请教 mssql 数据表 如何合理创建索引，是分开建还是合在一起建
石沫（A13）：我曾经整理的关于索引的设计与规范，可以供你参考：
-----------------------------------------------------------------------
索引设计与规范
1.1
SQL SERVER没有索引也可以检索数据，只不过检索数据时扫描这个表而异。存储数据的目的，绝大多数都是为了再次使用，而一般数据检索都是带条件的检索，数据查询在数据库操作中会占用较大的比例，提高查询的效率往往意味着整个数据库性能的提升。索引是特定列的有序集合。索引使用B-树结构，最小优化了定位所需要的键值的访问页面量，包含聚集索引和非聚集索引两大类。聚集索引与数据存放在一起，它决定表中数据存储的物理顺序，其叶子节点为数据行。
1.2
1.2.1
没聚集索引的表叫堆。堆是一种没有加工的数据，以行标示符作为指向数据存储位置的指针，数据没有顺序。聚集索引的叶子页面和表的数据页面相同，因此表行物理上按照聚集索引列排序，表数据的物理顺序只有一种，所以一个表只有一个聚集索引。
1.2.2
非聚集索引的一个索引行包含指向表对应行的指针，这个指针称为行定位器，行定位器的值取决于数据页保存为堆还是被聚集。若是堆，行定位器指向的堆中数据行的行号指针，若是聚集索引表，行定位器是聚集索引键值。
1.2.3
1.3
1.3.1
非聚集索引不影响表页面中数据的顺序，其叶子页面和表的数据页面时分离的，需要一个行定位器来导航数据，在将聚集索引时已经有说明，非聚集索引在读取少量数据行时特别有效。非聚集索引所有可以有多个。同时非聚集有很多其他衍生出来的索引类型，比如覆盖索引，过滤索引等。
1.3.2
1.3.3
书签会访问索引之外的数据，在堆表，书签查找会根据RID号去访问数据，若是聚集索引表，一般根据聚集索引去查找。在查询数据时，要分两个部分来完成，增加了读取数据的开销，增加了CPU的压力。在大表中，索引页面和数据页面一般不会临近，若数据只存在磁盘，产生直接随机从磁盘读取，这导致更多的消耗。因此，根据实际需要优化书签查找。解决书签查找有如下方法：
1.4
1.4.1
一般地，检索数据量大的一般使用聚集索引，因为聚集索引的叶子页面与数据页面在相同。相反，检索少量的数据可能非聚集索引更有利，但注意书签查找消耗资源的力度，不过可考虑覆盖索引解决这个问题。
1.4.2
如果数据需要预先排序，需要使用聚集索引，若不需要预先排序就那就选择聚集索引。
1.4.3
索引键如果太宽，不仅会影响数据查询性能，还影响非聚集索引，因此，若索引键比较小，可以作为聚集索引，如果索引键够大，考虑非聚集索引，如果很大的话，可以用INCLUDE创建覆盖索引。
1.4.4
列更新频率高的话，应该避免考虑所用非聚集索引，否则可考虑聚集索引。
1.4.5
如果书签查找开销较大，应该考虑聚集索引，否则可使用非聚集索引，更佳是使用覆盖索引，不过得根据具体的查询语句而看。
1.5
覆盖索引可显著减少查询的逻辑读次数，使用INCLUDE语句添加列的方式更容易实现，他不仅减小索引中索引列的数据，还可以减少索引键的大小，原因是包含列只保存在索引的叶子级别上，而不是索引的叶子页面。覆盖索引充当一个伪的聚集索引。覆盖索引还能够有效的减少阻塞和死锁的发生，与聚集索引类似，因为聚集索引值发生一次锁，非覆盖索引可能发生两次，一次锁数据，一次锁索引，以确保数据的一致性。覆盖索引相当于数据的一个拷贝，与数据页面隔离，因此也只发生一次锁。
1.6
如果一个表有多个索引，那么可以拥有多个索引来执行一个查询，根据每个索引检索小的结果集，然后就将子结果集做一个交叉，得到满足条件的那些数据行。这种技术可以解决覆盖索引中没有包含的数据。
1.7
几乎是跟索引交叉类似，是一个衍生品种。他将覆盖索引应用到交叉索引。如果没有单个覆盖索引查询的索引而多个索引一起覆盖查询，SQL SERVER可以使用索引连接来完全满足查询而不需要查询基础表。
1.8
用来在可能没有好的选择性的一个或者多个列上创建一个高选择性的关键字组。例如在处理NULL问题比较有效，创建索引时，可以像写T-SQL语句一样加个WHERE条件，以排除某部分数据而检索。
1.9
索引视图在OLAP系统上可能有胜算，在OLTP会产生过大的开销和不可操作性，比如索引视图要求引用当前数据库的表。索引视图需要绑定基础表的架构，索引视图要求企业版，这些限制导致不可操作性。
1.10
1.10.1
检查WHERE条件列的可选择性和数据密度，根据条件创建索引。一般地，连接条件上应当考虑创建索引，这个涉及到连接技术，暂时不说明。
1.10.2
窄的索引有可减少IO开销，读取更少量的数据页。并且缓存更少的索引页面，减少内存中索引页面的逻辑读取大小。当然，磁盘空间也会相应地减少。
1.10.3
数据分布比较集中的列，种类比较少的列上创建索引的有效性比较差，如果性别只有男女之分，最多还有个UNKNOWN，单独在上面创建索引可能效果不好，但是他们可以为覆盖索引做出贡献。
1.10.4
索引的数据类型是很重要的，在整数类型上创建的索引比在字符类型上创建索引更有效。同一类型，在数据长度较小的类型上创建又比在长度较长的类型上更有效。
1.10.5
对于包含多个列的索引，列顺序很重要。索引键值在索引上的第一上排序，然后在前一列的每个值的下一列做子排序，符合索引的第一列通常为该索引的前沿。同时要考虑列的唯一性，列宽度，列的数据类型来做权衡。
1.10.6
使用索引类型前面已经有较多的介绍，怎么选择已经给出。不再累述。
板砖大叔（Q14）：mssql表和字段命名方面有没有什么规范，驼峰还是加下划线
石沫（A14）：这两种都可以吧。看个人的喜好，不过微软现在的统一风格是下划线，比如表sys.all_columns/sys.tables，然后你再看他的列全是下划线连接，name
我个人的喜好也是喜欢下划线。
我们将赠送以上11位提问者每人一本凌云杂志第四期，请各位以论坛短消息
zc_0101（Q1）：请问大神石沫：如何判断MSSQL数据库磁盘出现了瓶颈？
石沫（A1）：您好，您的问题非常好，SQL SERVER提供了很多关于I/O压力的性能计数器，请选择性能计算器PhysicalDisk（LogicalDisk），根据我们的经验，如下指标的阈值可以帮助你判断IO是否存在压力：
1.
2.
3.
4.
5.
6.
7.
以上，请根据自己的磁盘系统判断，比如传统的机械臂磁盘和SSD有所不同。
一般磁盘的优化方向是：
1. 硬件优化：比如使用更合理的RAID阵列，使用更快的磁盘驱动器，添加更多的内存
2. 数据库设置优化：比如创建多个文件和文件组，表的INDEX和数据放到不同的DISK上，将数据库的日志放到单独的物理驱动器，使用分区表
3. 数据库应用优化：包括应用程序的设计，SQL语句的调整，表的设计的合理性，INDEX创建的合理性，涉及的范围很广
希望对您有所帮助，谢谢！
鹰舞（Q2）：MSSQL 2012的alwayson技术已经在线上使用了，但是发现在辅助副本上经常会出现AG延迟的情况，检查是因为辅助副本中的业务长时间查询导致了AG进程的还原block，锁是意向架构锁，请问下这个是什么原因导致呢？有什么办法可以避免此问题？
石沫（A2）：您好，根据您的描述，由于查询产生了副本REDO LOG延迟，出现了架构锁。我们知道SQL SERVER 2012 AlwaysOn在某些数据库行为上有较多变化。我们先看看架构锁：
架构锁分成两类：
1. SCH-M：架构更改锁，主要发生在数据库SCHEMA的修改上，从你的描述看，没有更改SCHEMA，那么可以排除这个因素
2. SCH-S：架构稳定锁，主要发生在数据库的查询编译等活动
根据你的情况，应该属于SCH-S导致的。查询编译活动主要发生有新增加了INDEX, 更新了统计信息，未参数化的SQL语句等等
对于INDEX和SQL语句方面应，我想应该不会有太多问题。
我们重点关注一下统计信息：SQL SERVER 2012 AG副本的统计信息维护有两种：
1. 主体下发到副本
2. 临时统计信息存储在TEMPDB
对于主体下发的，我们可以设置统计信息的更新行为，自动更新时，可以设置为异步的（自动更新统计信息必须首先打开）：
USE [master]
GO
ALTER DATABASE [Test_01]
WITH NO_WAIT
GO
这样的话查询优化器不等待统计信息更新完成即编译查询。可以优化一下你的BLOCK。
对于临时统计信息存储在TEMPDB里面也是很重要的，再加上ALWAYSON的副本数据库默认是快照隔离，优化TEMPDB也是必要的，关于优化TEPDB这个我想大部分都知道，这里只是提醒一下。
除了从统计信息本身来解决，在查询过程中，可以降低查询的时间，以尽量减少LOCK的时间和范围，这需要优化你的SQL语句或者应用程序。
以上，希望对您有所帮助。谢谢！
leamonjxl（Q3）：目前有一个表，主键为ID自增，数据量很小，更新的并发也不是特别高，Update的条件是表中的另外两个联合字段，但是经常会出现死锁情况，请问是否只有通过修改聚集索引的方式来处理呀，非常感谢。
石沫（A3）：这是一个关于死锁的问题，为了能够提供帮助一些。请根据下列建议进行：
1.
2.
3.
关于跟踪死锁，我们首先需要打开1222标记，例如DBCC TRACEON(1222,-1), 他将收集的信息写入到死锁事件发生的服务器上的日志文件中。同时建议打开Profiler的跟踪信息：
如果发生了死锁，需要分析死锁发生的根源在哪里？我们不是很清楚你的具体发生死锁的形态是怎么样的。
关于死锁的实例也多，这里不再举例。
这里只是提出一些可以解决的思路：
1.
2.
3.
减少锁的争用，可以从几个方面入手
1.
2.
减少资源的访问数，可以从如下几个方面入手：
1.
2.
按照相同的时间顺序访问资源：
确保每个事务按照相同的物理顺序访问资源。两个事务按照相同的物理顺序访问，第一个事务会获得资源上的锁而不会被第二个事务阻塞。第二个事务想获得第一个事务上的LOCK，但被第一个事务阻塞。这样的话就不会导致循环阻塞的情况。
leamonjxl（Q4）：一个数据量超过10亿的表，大神是建议物理分表+视图，还是分区表，这两者性能差距很大么，谢谢。
石沫（A4）：两种方式看你的业务怎么应用。这里不仅是分表的问题，还可能存在分库，分服务器的问题。取决与你的架构方案。
物理分表+视图，这是一种典型的冷热数据分离的方案，大致的做法如下：
1.
2.
分表后，涉及到几个问题：
第一问题是，转移数据的过程，一般是晚上业务比较闲来转移，转移按照一定的规则来做，始终保持3个月，这个定时任务本身也很消耗时间
再者，关于查询部分，我想你们的数据库服务器应该通过REPLICATION做了读写分离的吧，主库我觉得压力不会太大，主要是插入或者更新，只读需要做视图来包含全部的数据，但通过UNION ALL所有分表的数据，最后可能还是非常大，在某些情况下，性能不一定好。这个是不是业务上可以解决。比如，对于1年前的历史数据，放在单独的只读上，相对热的数据放在一起，这样压力也会减少。
分区表的话，因为涉及到10亿数据，要有好的分区方案，相对比较简单一点。但对于10亿的大表，始终是个棘手的问题，无论分多少个分区，单个服务器的资源也是有限的。可扩展性方面也存在问题，比如在只读上你没有办法做服务器级别的拆分了。这可能也会造成瓶颈。
现在很多企业都在做分库分表，这些的要解决一些高并发，数据量大的问题。不知是否考虑过类似于中间件的方案，比如阿里巴巴的TDDL类似的方案，如果你有兴趣，可以查询相关资料。
jiangnii（Q5）：请教石沫大神，MSSQL云数据库的运维和优化，与在普通服务器上的优化是否有某些区别，在云数据库上处理大数据量或复杂的数据操作时有没有什么需要特别注意的地方？ 希望听听您的经验，谢谢！
石沫（A5）：阿里云数据库不仅提供一个数据库，还提供数据库一种服务。阿里云数据库不仅简化了基础架构的部署，还提供了数据库高可用性架构，备份服务，性能诊断服务，监控服务，专家服务等等，保证用户放心、方便、省心地使用数据库，就像水电一样。以前的运维繁琐的事，全部由阿里云接管，用户只需要关注数据库的使用和具体的业务就好。
关于优化和在云数据库上处理大数据量或复杂的数据操作方面，在云数据库上是一样的，没有什么特别的地方，不过我们的云数据库是使用SSD磁盘，这个比普通的磁盘要快很多，IO上有很大的优势。目前单个实例支持1T的数据量大小。陆续我们会推出更多的服务，比如索引诊断，连接诊断，容量分析，空间诊断等等，这些工作可能是专业的DBA才能完成的，以后我们会提供自动化的服务来为客户创造价值，希望能帮助到客户。 谢谢！
daniellin17（Q6）：有个问题想请教大神石沫：有时候碰到 使用ssms和程序连接到实例，运行同一个proc， 结果时间,io开销有明显的差距，执行计划也不一样。请帮忙分析一下原因，以及是否有什么解决办法。
石沫（A6）：这个过程确实有遇到过，定位原因有多种可能。不过我们分析下面几个方向入手：
1.
2.
3.
4.
执行计划缓冲，你可以观察到你的语句到底使用了那个查询计划：
SELECT
FROM sys.dm_exec_cached_plans cp
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st
WHERE st.text LIKE '%********%'
对比你的两种查询计划，如果你确定哪种查询计划不是需要，但又被命中了，可以考虑将不需要的删除掉（但需要慎重），例如：
DBCC FREEPROCCACHE (0x060002007FEA040740C17E
查看你的统计信息情况，你可以。你可以看看你的统计信息是否失效，是否过时，同时更新统计信息使用FULLSAN扫描表或索引视图中的所有行来计算统计信息。同时查看一下相关执行计划变化对象的列的统计分布：
DBCC SHOW_STATITICS(***)
关于你的两种环境执行计划不一样，你提供的参数是否一致，有个参数嗅探的问题，不同的参数可能产生不一样的执行计划，有些执行计划是良好的，有些是给性能造成危害的。这个也需要关注一下，若确定是这个问题，解决这个的办法也很多，比如执行时加WITH RECOMMPILE。,还比如指定查询提示OPTIMIZE FOR等等。另外，你可以将输入参数赋予本地参数，强制优化器查看所引用的数据的统计来对可能使用的值做出好的评估。
存储过程重编译也是一种可能,大致原因有如下,可排查一下，不过根据你的描述应该不是这些原因，只是一个方向:
1.
2.
3.
4.
5.
另外，你可以分析你的语句和变化的执行计划，创建一个更合理的INDEX可能会解决你的问题。同时，你也可以强制指定INDEX,使用WITH (FORCESEEK),不要使用WITH (INDEX=***)
daniellin17（Q7）：你好石沫大神： 还有一个问题，能否根据你多年的经验 谈谈如何增大并行度。 比如说从db的设计层面，还有物理设备，参数配置等等....
石沫（A7）：这个问题我不知道是否是两个问题，一个是并行度，另一个是并发，我更多理解是吞吐量，单就并行度而言。
提高并行度需要考虑的因素有：
1.
2.
3.
4.
5.
6.
7.
以DOP的参数控制并行度为例，设置如下：
SELECT *
FROM sys.configurations WITH (NOLOCK)
WHERE name = 'max degree of parallelism'
EXEC sp_configure 'max degree of parallelism',2
RECONFIGURE WITH OVERRIDE
经过测试，DOP设置为2是一个比较适中的状态，特别是OLTP应用。如果设置高了，会产生较多的SUSPEND进程。我们可以观察到资源等待资源类型是：CXPACKET
你可以用下列语句去测试：
DBCC SQLPERF('sys.dm_os_wait_stats',CLEAR)
SELECT *
FROM sys.dm_os_wait_stats WITH (NOLOCK)
ORDER BY 2 DESC ,3 DESC
如果是吞吐量的话。优化的范围就很广了。优化是系统性的。硬件配置我们选择的话，大多根据业务量来预估，然后考虑以下：
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
我这里列举一个高并发的场景：
比如，我们的订单，比如搞活动的时候，订单刷刷刷地增长，单个实例可能每秒达到很高很高，我们分析到最后最常见的问题是HOT PAGE问题，其等待类型是PAGE LATCH竞争。这个过程可以这么来处理，简单列几点，可以参考很多涉及高并发的案例：
1.
2.
3.
4.
5.
这个场景只是针对高并发的插入。对于查询而言，是不适合的。但这些也可能导致大量的页拆分。只是在不同的场景有不同的设计思路。这里抛砖引玉。
zuijh（Q8）：ECS
石沫（A8）：ECS上现在有两种磁盘，一种是传统的机械臂磁盘，另一种是SSD，请先诊断你的IO是否出现了问题，本帖中有提到如何判断磁盘出现问题的相关话题，请参考。如果确定IO出现问题，可以尝试使用ECS LOCAL SSD。当然，我们欢迎你使用云数据库的产品，云数据库提供了很多有用的功能，比如高可用性，灵活的备份方案，灵活的弹性方案，实用的监控报警等等。
豪杰本疯子（Q9）：请教大神石沫，mssql数据到后期数据库越大，查询越频繁，可以通过什么硬件和技术来处理后期效率和安全的问题？
石沫（A9）：我们单个主机或者单个实例的资源总是有限的，因为涉及到很大的数据量，对于存储而言是个瓶颈，我曾使用过SAN和SAS存储，SAN存储的优势确实可以解决数据的灵活扩展，但是SAN也分IPSAN和FIBER SAN，如果IPSAN的话，性能会差一些。即使是FIBER SAN，也不是很好解决性能问题，这不是它的优势，同时，我们所有DB SERVER都连接到SAN上，如果SAN有问题，问题涉及的面就很广。但是SAS毕竟空间也是有限的。最终也会到瓶颈。数据量大，是造成性能问题的直接原因，因为我们不管怎么优化，一旦数据量太大，优化的能力总是有限的，所以这个时候更多从架构上考虑。单个主机单个实例肯定是抗不过来的。
所以现在很多企业在向分布式系统发展，对于数据库而言，其实有很多形式。我们最常见的是读写分离，比如SQL SERVER而言，我们可以通过复制来完成读写分离，SQL SERVER 2012及以后的版本，我们可以使用ALWAYSON来实现读写分离，但这只能解决性能问题，那空间问题怎么解决。我们就涉及到分库分表，这个分库分表跟应用结合得紧密，现在很多公司通过中间件来实现，比如TDDL。但是中间件不是每个公司都可以玩得转的。因此可以将业务垂直拆分，那么DB也可以由此拆分开来。举个简单例子，我们一个典型的电子商务系统，有订单，有促销，有仓库，有配送，有财务，有秒杀，有商品等等，很多公司在初期，都是将这些放在一个主机一个实例上。但是这些到了一定规模或者一定数据量后，就会出现性能和硬件资源问题，这时我们可以将它们独立一部分获完全独立出来。这些都是一些好的方向。希望对你有所帮助。
dt（Q10）：求大数据量下mysql存储，优化方案 ，分区好还是分表好，分的过程中需要考虑事项，mysql高并发读写的一些解决办法
石沫（A10）：分区：对于应用来说比较简单,改造较少
分表: 应用需较多改造，优点是数据量太大的情况下，分表可以拆分到多个实例上，而分区不可以。
高并发优化,有两个建议:
1.
2.
http://www.open-open.com/doc/view/d58cadb4fb68429587634a77
aelven（Q11）：请问大神石沫：
1.MSSQL2008 适合用于大型网站大并发大访问量的像携程网这类的酒店预订网站吗(例如连接数量比较大,频繁更新酒店价格)
2.连接数比较大更新频率比较高 比如像1个表里存储着100条酒店数据每条数据有1个列是价格,这个类更新的频率很高,我的是asp.net程序用存储过程会更好吗?
3.自己用阿里云搭建的数据服务器和 用阿里云的rds mssql相比起来会差别很大吗? 阿里云的mssql是不是有比较好的安全防护,和基本的优化?
石沫（A11）：对于第一个问题.需要看看你的数据库架构是什么样的?比如你的架构具有高可用行?具有读写分离的架构?具有群集的架构.数据库应用是否有较冷门的功能。高并发应该不是什么问题。可扩展性方面需要考虑。阿里云数据库提供了很多优势，比如磁盘是性能超好的SSD，自动转移的高可用性，没有任何单点，自动灵活的备份方案，实用的监控报警，性能监控服务等等，省去DBA很多基础性工作。
你第二个问题，看起来是一个高并发的场景，这种高并发的场景容易出现大量的LOCK甚至死锁，我不是很清楚你的业务，但可以建议一下，首先可以考虑快照隔离级别，实现行多版本控制，让读写不要阻塞。至于写写过程，需要加锁的粒度降低最低，同时这种高并发也容易出现死锁，关于死锁的分析，本帖有提到，请关注。
第三个问题，你用ECS搭建自己的应用也是可以的，RDS数据库提供了很多功能，上面已经讲到了。安全问题一直是我们最看重的问题，肯定有超好的防护的。
cherish_j（Q12）：作为从业多年的DBA角度考虑，MSSQL Server哪些方面还需要加以改进，或者说目前的产品瓶颈在哪里？
石沫（A12）：哈哈，这是跟MS拉仇恨不是，不过我们尝试给他们提供一些建议。就我而言，也可能是大家关心的几个问题：
1.
2.
3.
板砖大叔（Q13）：请教 mssql 数据表 如何合理创建索引，是分开建还是合在一起建
石沫（A13）：我曾经整理的关于索引的设计与规范，可以供你参考：
-----------------------------------------------------------------------
索引设计与规范
1.1
SQL SERVER没有索引也可以检索数据，只不过检索数据时扫描这个表而异。存储数据的目的，绝大多数都是为了再次使用，而一般数据检索都是带条件的检索，数据查询在数据库操作中会占用较大的比例，提高查询的效率往往意味着整个数据库性能的提升。索引是特定列的有序集合。索引使用B-树结构，最小优化了定位所需要的键值的访问页面量，包含聚集索引和非聚集索引两大类。聚集索引与数据存放在一起，它决定表中数据存储的物理顺序，其叶子节点为数据行。
1.2
1.2.1
没聚集索引的表叫堆。堆是一种没有加工的数据，以行标示符作为指向数据存储位置的指针，数据没有顺序。聚集索引的叶子页面和表的数据页面相同，因此表行物理上按照聚集索引列排序，表数据的物理顺序只有一种，所以一个表只有一个聚集索引。
1.2.2
非聚集索引的一个索引行包含指向表对应行的指针，这个指针称为行定位器，行定位器的值取决于数据页保存为堆还是被聚集。若是堆，行定位器指向的堆中数据行的行号指针，若是聚集索引表，行定位器是聚集索引键值。
1.2.3
1.3
1.3.1
非聚集索引不影响表页面中数据的顺序，其叶子页面和表的数据页面时分离的，需要一个行定位器来导航数据，在将聚集索引时已经有说明，非聚集索引在读取少量数据行时特别有效。非聚集索引所有可以有多个。同时非聚集有很多其他衍生出来的索引类型，比如覆盖索引，过滤索引等。
1.3.2
1.3.3
书签会访问索引之外的数据，在堆表，书签查找会根据RID号去访问数据，若是聚集索引表，一般根据聚集索引去查找。在查询数据时，要分两个部分来完成，增加了读取数据的开销，增加了CPU的压力。在大表中，索引页面和数据页面一般不会临近，若数据只存在磁盘，产生直接随机从磁盘读取，这导致更多的消耗。因此，根据实际需要优化书签查找。解决书签查找有如下方法：
1.4
1.4.1
一般地，检索数据量大的一般使用聚集索引，因为聚集索引的叶子页面与数据页面在相同。相反，检索少量的数据可能非聚集索引更有利，但注意书签查找消耗资源的力度，不过可考虑覆盖索引解决这个问题。
1.4.2
如果数据需要预先排序，需要使用聚集索引，若不需要预先排序就那就选择聚集索引。
1.4.3
索引键如果太宽，不仅会影响数据查询性能，还影响非聚集索引，因此，若索引键比较小，可以作为聚集索引，如果索引键够大，考虑非聚集索引，如果很大的话，可以用INCLUDE创建覆盖索引。
1.4.4
列更新频率高的话，应该避免考虑所用非聚集索引，否则可考虑聚集索引。
1.4.5
如果书签查找开销较大，应该考虑聚集索引，否则可使用非聚集索引，更佳是使用覆盖索引，不过得根据具体的查询语句而看。
1.5
覆盖索引可显著减少查询的逻辑读次数，使用INCLUDE语句添加列的方式更容易实现，他不仅减小索引中索引列的数据，还可以减少索引键的大小，原因是包含列只保存在索引的叶子级别上，而不是索引的叶子页面。覆盖索引充当一个伪的聚集索引。覆盖索引还能够有效的减少阻塞和死锁的发生，与聚集索引类似，因为聚集索引值发生一次锁，非覆盖索引可能发生两次，一次锁数据，一次锁索引，以确保数据的一致性。覆盖索引相当于数据的一个拷贝，与数据页面隔离，因此也只发生一次锁。
1.6
如果一个表有多个索引，那么可以拥有多个索引来执行一个查询，根据每个索引检索小的结果集，然后就将子结果集做一个交叉，得到满足条件的那些数据行。这种技术可以解决覆盖索引中没有包含的数据。
1.7
几乎是跟索引交叉类似，是一个衍生品种。他将覆盖索引应用到交叉索引。如果没有单个覆盖索引查询的索引而多个索引一起覆盖查询，SQL SERVER可以使用索引连接来完全满足查询而不需要查询基础表。
1.8
用来在可能没有好的选择性的一个或者多个列上创建一个高选择性的关键字组。例如在处理NULL问题比较有效，创建索引时，可以像写T-SQL语句一样加个WHERE条件，以排除某部分数据而检索。
1.9
索引视图在OLAP系统上可能有胜算，在OLTP会产生过大的开销和不可操作性，比如索引视图要求引用当前数据库的表。索引视图需要绑定基础表的架构，索引视图要求企业版，这些限制导致不可操作性。
1.10
1.10.1
检查WHERE条件列的可选择性和数据密度，根据条件创建索引。一般地，连接条件上应当考虑创建索引，这个涉及到连接技术，暂时不说明。
1.10.2
窄的索引有可减少IO开销，读取更少量的数据页。并且缓存更少的索引页面，减少内存中索引页面的逻辑读取大小。当然，磁盘空间也会相应地减少。
1.10.3
数据分布比较集中的列，种类比较少的列上创建索引的有效性比较差，如果性别只有男女之分，最多还有个UNKNOWN，单独在上面创建索引可能效果不好，但是他们可以为覆盖索引做出贡献。
1.10.4
索引的数据类型是很重要的，在整数类型上创建的索引比在字符类型上创建索引更有效。同一类型，在数据长度较小的类型上创建又比在长度较长的类型上更有效。
1.10.5
对于包含多个列的索引，列顺序很重要。索引键值在索引上的第一上排序，然后在前一列的每个值的下一列做子排序，符合索引的第一列通常为该索引的前沿。同时要考虑列的唯一性，列宽度，列的数据类型来做权衡。
1.10.6
使用索引类型前面已经有较多的介绍，怎么选择已经给出。不再累述。
板砖大叔（Q14）：mssql表和字段命名方面有没有什么规范，驼峰还是加下划线
石沫（A14）：这两种都可以吧。看个人的喜好，不过微软现在的统一风格是下划线，比如表sys.all_columns/sys.tables，然后你再看他的列全是下划线连接，name
我个人的喜好也是喜欢下划线。
我们将赠送以上11位提问者每人一本凌云杂志第四期，请各位以论坛短消息
扫一扫
392
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
