改进NET应用程序的性能和可伸缩性-SQL Server性能.doc

Optimize the application before scaling up or scaling out.在你进行向上扩容和平面扩容前优化你的应用。译注：你可以减少无效的锁，使用参数化查询，增加合适的索引等操作来提高磁盘，内存和CPU的利用率。Address historical and reporting data.处理历史和用于报表的数据。译注：一个运行时间很长的系统肯定有很多历史数据，在现网库里一直保存这些数据，肯定会给线上的应用带来负面影响，查询一个小库和查询一个大库的开销差别很大，所以一般应该把历史数据的一部分分到不同的区里，历史数据是只读的，甚至可以放到另外的只读数据库里。用于报表的数据也是，大多都是历史数据，可以建立单独的数据仓库去存放他们，不要和现网库放在一起。Scale up for most applications.对大多数应用进行向上扩容。译注：如果你在处理了历史数据和报表数据后还有更好的硬件，那就先添加这些新的硬件，比如更快的CPU和硬盘，更大的内存等，但添加了新的硬件后记着修改你的SQLSERVER的配置以适应这些新硬件，比如要打开/3G开关以使用更多的内存。Scale out when scaling up does not suffice or is cost-prohibitive.在你向上扩容仍不满足或者向上扩容成本太高的时候使用横向扩容。译注：横向扩容的时候可能需要对一些表进行水平分区，使这些分区到不同的机器上，而这种办法可能需要在多台机器间用SQLSERVER的复制功能复制数据。而且使用大量的PC server做成的联合服务器在在灾后恢复和容灾上也更加复杂，你需要权衡引入这些复杂性和花钱买硬件哪个更值得。SchemaDevote the appropriate resources to schema design.给予适当的资源用来进行schema设计。译注：在进行架构设计前一定要花费足够的时间和投入足够的资源来进行业务逻辑收集，设计及测试数据模型，如果上线之后再修改数据模型代价将非常高。Separate online analytical processing (OLAP) and online transaction processing (OLTP) workloads.分割OLAP和OLTP负载。译注：OLAP的特点是经常执行一些长时间的查询，OLTP的特点是都是小而多的事务，一般在1秒中就得返回，长时间运行的查询分析，报表查询和即席查询会阻碍插入和其它OLTP的事务。如果需要同时支持两种类型的工作，考虑创建一个报表服务器来支持OLAP和报表，可以使用SSAS来支持这些工作。Normalize first, denormalize later for performance.先遵守范式设计数据库，然后再不遵守范式来优化性能。译注：遵循范式设计数据库可以让数据库减少冗余，但写出来的查询语句却很复杂，带有很多join等，而且会降低性能，有时候为了防止一些常用的查询跨表查询，会在多个表里存放相同的数据，以提高性能，但这违反了范式。Define all primary keys and foreign key relationships.确定所有的主键和外键关系。译注：选择合适的主键和外键关系会很大程度上影响查询计划的生成，从而影响性能。另外可考虑使用声明性引用完整性 (DRI) ，设置好主外键和DRI的情况下，更新主表会自动修改子表，级联更新和级联删除等，而且性能比触发器要好。Define all unique constraints and check constraints.确定所有的唯一索引和约束。译注：唯一索引和检查约束为查询计划提供了更多的信息，比如你做了一个id列不等于0的约束，如果你一个查询语句查询id=0的数据，就不用扫描任何数据表，只检查约束就可以了。Choose the most appropriate data type.选择最适合的数据类型。译注：尽量选用比较窄的类型，能用smallint不用int，选择合适的类型，避免类型转换，需要类型转换的查询语句有可能不能有效利用索引；避免外键列允许为空[不确定]；能用varchar的地方不要用Text字段，Text字段性能不行；尽量少使用sql_variant，虽然灵活，但使用它会带来更多的类型转换而降低性能；因为win2000和.net里的字符串都是unicode的，所以尽量使用nchar和nvarchar，虽然它比较占空间，但像存储电话号码和邮件等用varchar和char就行了[该条可能有争议，我不确认]。Use ind