發糞塗牆-CSDN博客

翻译理解性能的奥秘——应用程序中慢，SSMS中快（2）——SQL Server如何编译存储过程

本文属于《理解性能的奥秘——应用程序中慢，SSMS中快》系列接上文：理解性能的奥秘——应用程序中慢，SSMS中快（1）——简介本文介绍SQL Server如何编译存储过程并使用计划缓存。如果你的应用程序完全没有用到存储过程，而是直接使用SQL语句提交请求，那么本文大部分内容也是有效的。但是关于动态SQL的编译会在后面章节介绍，这里重点关注让人头痛的存储过程问题。什么是存储过程？虽然这个问题有...

2016-11-15 10:38:44 6901

翻译理解性能的奥秘——应用程序中慢，SSMS中快（1）——简介

在工作中发现有不少类似的现象，有幸看到国外大牛写的一篇文章，由于已经完善得不能再添油加醋，所以决定直接翻译，原文出处：http://www.sommarskog.se/query-plan-mysteries.html#defaultsettings 本人水平有限，如果读者觉得自己英语过得去，建议阅读原文。在翻译过程中，不排除会对某些部分进行修改，但不会影响最终效果。由于内容较多，所以把文章拆

2016-11-14 23:24:30 4524

原创全废话SQL Server统计信息（2）——统计信息基础

我想在大地上画满窗子，让所有习惯黑暗的眼睛习惯光明——顾城《我是一个任性的孩子》这一节主要介绍一些理论层面的东西，主要针对SQL Server，为后面的做铺垫，如果从实操层面考虑可以跳过，但是我强烈建议还是要找时间看一下这节。本节的内容如下：SQL Server统计信息列级统计信息统计信息与执行计划统计信息与内存分配开销预估模型SQL Server统计信息说到统计信息，就一定要提到查询优化器，

2016-11-01 23:18:49 11564 8

原创全废话SQL Server统计信息（1）——统计信息简介

为什么要写这个内容？随着工作经历的积累，越来越感觉到，大量的关系型数据库的性能问题，其根源在于统计信息。这里说的是根源，其实很多时候大家觉得的那些什么索引失效等都只是表象。当然，不能一概而论，还有很多问题如配置问题、设计问题等等，甚至电源也会影响性能。之所以得出这个结论，因为在常规的开发和部署过程中，一般企业级系统已经大量使用较为高级的磁盘阵列甚至企业级SSD，IO方面的问题已经很少，而且关系

2016-11-01 23:17:19 6887

原创 T-SQL注意事项（1）——SET NOCOUNT ON的去与留

前言用了一段时间T-SQL之后，哪怕自己没用过，也多多少少看过SSMS中的SET NOCOUNT ON命令，很多性能优化文章中都有提到这个东西，它们建议尽可能使用这个命令减少网络传输的压力，那么今天来看看它是否是个鸡肋。

2016-03-17 16:21:13 10156 5

原创 SQL Server专家的10个秘诀（翻译加注解）

当你点开这篇文章的时候，如果觉得没有读下去的必要，也希望你能拉到最后看看那几行字！原文出处：https://technet.microsoft.com/en-us/magazine/gg299551.aspx译者注：本文主要以翻译为主，但由于工作经历，译者也有一些自己的看法和心得，并且不打算完全照搬直译，期间过滤了一些本人觉得无关紧要的信息，如果读者觉得看的别扭，可以看原文。这篇文章可能已被广

2016-02-14 17:24:02 11595 14

原创 SQL Server 执行计划操作符详解（3）——计算标量(Compute Scalar)

接上文：SQL Server 执行计划操作符详解（2）——串联(Concatenation )

2016-01-06 17:27:42 7040 2

原创 SQL Server性能优化——等待——SLEEP_BPROOL_FLUSH

前言：有一个用于历史归档的数据库（简称历史库），经过一定时间的积累，数据文件已经达到700多GB，后来决定某些数据可以不需要保留，就把这部分数据truncate了，空余出600多GB的空间，也就是说，经过收缩后，理论上数据库只有100多G。为此，我经过重建各个表（表数量不多，但单表数量还是有几千万）的聚集索引后，准备进行收缩。但是当收缩开始时，即使把每次收缩的范围缩小到500MB，速度也极其慢

2016-01-04 14:07:28 6174 2

原创 SQL Server 执行计划操作符详解（2）——串联(Concatenation )

本文接上文：SQL Server 执行计划操作符详解（1）——断言(Assert)前言：根据计划，本文开始讲述另外一个操作符串联（Concatenation），读者可以根据这个词（中英文均可）先幻想一下是干嘛的。其实还是挺直观，就是把东西连起来，那么下面我们来看看到底连什么？怎么连？什么时候连？

2015-12-16 10:52:11 5777 1

原创 SQL Server 执行计划操作符详解（1）——断言(Assert)

前言：很多很多地方对于语句的优化，一般比较靠谱的回复即使——把执行计划发出来看看。当然那些只看语句就说如何如何改代码，我一直都是拒绝的，因为这种算是纯蒙。根据本人经验，大量的性能问题单纯从语句来看很难发现瓶颈，同一个语句，由于环境的不同，差距非常大，所以比较合适的还是分析执行计划。那么对于执行计划，一般使用图形化执行计划就差不多了，但是用过的人也有一些疑惑，里面的图标（称为操作符）并不非常

2015-12-11 14:38:43 12171 4

原创 T-SQL动态查询（4）——动态SQL

接上文：T-SQL动态查询（3）——静态SQL 前言：前面说了很多关于动态查询的内容，本文将介绍使用动态SQL解决动态查询的一些方法。为什么使用动态SQL：在很多项目中，动态SQL被广泛使用甚至滥用，很多时候，动态SQL又确实是解决很多需求的首选方法。但是如果不合理地使用，会导致性能问题及无法维护。动态SQL尤其自己的优缺点，是否使用需要进行评估分析：动态SQL优点：动态SQL提供了强大的扩

2015-12-09 09:38:17 13246 2

原创 T-SQL动态查询（3）——静态SQL

接上文：T-SQL动态查询（2）——关键字查询本文讲述关于静态SQL的一些知识和基础技巧。简介：什么是静态SQL？静态SQL是和动态SQL相对而言的，其实我们没必要过于纠结精确定义，只要大概知道什么算静态SQL即可。当一个语句特别是存储过程，语句不需要动态生成或拼接，除了参数之外我们都知道语句的最终形态时，就可以认为这是静态SQL，简单来说，我们大部分的处理动态查询条件的语句都属于静态SQ

2015-11-26 16:01:48 6846

原创 T-SQL动态查询（2）——关键字查询

接上文：T-SQL动态查询（1）——简介前言：在开发功能的过程中，我们常常会遇到类似以下情景：应用程序有一个查询功能，允许用户在很多查询条件中选择所需条件。这个也是本系列的关注点。但是有时候你也许会发现，有些条件或多或少是互相排斥的。比如用户通过下面其中一个条件查找信息：1．客户名2．客户ID3．客户身份标识号（如国内身份证、美国社保号等）。并且这三列上都有适当的索引。本系列主

2015-11-19 16:39:43 5773 2

原创 T-SQL动态查询（1）——简介

起因：由于最近工作需要及过去一直的疑问，所以决定着手研究一下动态SQL。由于离开一线开发有点年头了，很多技巧性的东西没有过多研究，作为DBA和《SQL Server性能优化与管理的艺术》一书的独立作者，更多的是关注在满足功能要求前提下的性能问题。但是我认为本文不仅对DBA有用，对数据库开发人员甚至设计师、架构师等都有一定的参考价值。前言：读者是否遇到过类似功能：一个应用程序（不管是B/S还是

2015-11-19 16:27:58 10688 2

原创 SQL Server 索引维护（1）——如何获取索引使用情况

前言：在前面一文中，已经提到了三类常见的索引问题，那么问题来了，当系统出现这些问题时，该如何应对？简单而言，需要分析现有系统的行为，然后针对性地对索引进行处理：对于索引不足的情况：检查缺少索引的情况，也需要检查现有索引定义是否有问题。对于索引过多的情况：分析每一个索引的使用情况，判断是否有存在的必要或者可合并、可修改的可能。对于索引不合理的情况：也要分析每个索引的定义，及其使用情况，确定索引是

2015-11-09 12:57:32 11646 5

原创 SQL Server 索引维护（1）——系统常见的索引问题

前言：在很多系统中，比如本人目前管理的数据库，索引经常被滥用，甚至使用DTA（数据库引擎优化顾问）来成批创建索引（DTA目前个人认为它的真正用处应该是在发现缺失的统计信息，在以前的项目中，用过一次DTA，里面提示了很多列缺少统计信息，后来在不改动其他操作的前提下，把这些统计信息手动建上去，性能提升非常明显。关于统计信息将另开文章介绍）。一个表甚至有20多个索引（索引的数量并没有标准，但是要尽量

2015-11-09 10:54:12 8226 1

原创 T-SQL中的APPLY用法（半翻译）

本文接上文：T-SQL 中的CROSS JOIN用法（半翻译）同样可用于微软认证70-461: Querying Microsoft SQL Server 2012考试的学习中。 ---------------------------------------------------------------------以下为译文-----------------------------------

2015-09-18 14:38:33 7165

原创 T-SQL 中的CROSS JOIN用法（半翻译）

今天来翻译一篇关于T-SQL的文章，本文可供微软认证70-461:QueryingMicrosoft SQL Server 2012的学习和练习之用。本文以翻译为主，引出个人工作中的一些思考，详见最后部分。我会尽可能抽时间翻译本系列（见原文出处的相关链接，这是一系列的文章）的其他文章，除了回顾一些知识之外，重点是总结一下自己的所得。 -------------------------------

2015-09-15 13:09:07 7701

原创 SQL Server SA 最佳实践（也许不仅仅是翻译）

老实说，本文主要部分是翻译的，并且由于英语水平的问题，我没有完全翻译，有些我觉得不重要的就跳过了，目前看来应该八九不离十，或者说不会影响最终效果，对于英语水平好的读者，可以自行查看原文。但这一年里面我遇到了很多事情，也想了很多，我看的资料不少，但是记得的却少得可怜，要用的时候更加难以回忆。能知道从哪里找到就已经很幸运了。

2015-09-04 13:27:39 4496 5

翻译 Chapter 3 Protecting the Data（4）：创建和使用应用程序角色

数据库角色用于管理数据库内部的访问和权限。数据库角色成员是能通过客户端软件如SSMS连接SQL Server的数据库用户，但是你可能希望授予某个特殊用户一些特权，但是仅限制于某个应用程序而不是SSMS时，第一个解决方案是使用专用SQL 帐号作为应用程序的登录。但是这个方案的缺点是需要使用SQL Server身份验证，并且不能标识出哪个用户正在连接SQL Server。但是可以使用同一个应用程序登录名，并且使用Windows身份验证，因此能更好地标识应用程序的用户，从而在必要的时候提升权限。

2014-10-09 11:21:10 5546

翻译 Chapter 3 Protecting the Data（3）：创建和使用数据库角色

数据库层级的角色允许把数据库权限像服务器级别角色一样组合管理。你可以配置固定服务器角色，创建用户自定义角色等。

2014-09-28 12:41:57 5420

翻译 Chapter 3 Protecting the Data（2）：分配列级权限

SQL Server的权限是有层次的，一个用户有架构级别的权限，就有了架构内部所有对象的权限，除非使用了DENY权限单独移除。但是对象并不是层次中的最低级，可以把权限设置到列级别。但是列级权限会覆盖掉表上被GRANT的权限。

2014-09-26 11:09:25 4974

翻译 Chapter 3 Protecting the Data（1）：理解权限

关系型数据库管理系统（RDBMS），如SQL Server、Oracle、Mysql等，不仅仅需要负责存取数据，也要负责确保数据的一致性和安全性。类似于其他服务器系统，通过授权给一个用户并维护这个用户的会话来控制数据的访问行为。每当尝试读写数据时，SQL Server都会检查这些权限。

2014-09-25 11:47:05 5301

翻译 Chapter 2 User Authentication, Authorization, and Security（11）：在已还原的数据库中修正登录映射错误

如果你把非包含数据库从一个服务器移到另外一个服务器，不管是备份还原还是分离附加，都有可能导致SQL用户变成孤立用户，意味着他们没有对应的登录关联。因为登录名和用户之间的映射是基于SID的，即使新服务器上有相同的登录名，但是由于SID不同，也会使得用户无法被识别，从而形成孤立用户。如果在同一个域中迁移，那么映射问题仅会影响SQL登录，因为域账号（Windows身份验证）的SID在活动目录中是相同的。

2014-09-23 12:01:43 4664

翻译 Chapter 2 User Authentication, Authorization, and Security（10）：创建包含数据库

在SQL Server中，安全性分为两级：服务器级别和数据库级别。服务器的登录名被映射到数据库中的一个用户。身份验证在登录名连接到服务器时发生。如果数据库中有这个登录名所对应的用户，那么这个登录名就能访问数据库。登录名和用户之间的映射是基于一个内部SID，当从一个服务器复制数据库到另外一个服务器，即使用户名相同，如果SID不同，也会打算这个连接关系。从2012开始引入了包含数据库（Contained database）概念，用于解决这种问题。

2014-09-22 11:12:34 4609

翻译 Chapter 2 User Authentication, Authorization, and Security（9）：防止登录名和用户查看元数据

在SQL Server 2005之前，所有服务器和数据库元数据都是所有人可见的。当基于网银的系统把SQL Server实例共享给客户时，有可能可以看到其他用户的信息。从2005开始，可以通过控制权限来限制登录名或用户查看不必要的元数据。

2014-09-02 11:42:14 5030

翻译 Chapter 2 User Authentication, Authorization, and Security（8）：创建映射到登录名的数据库用户

登录名用于授权并访问服务器资源，如果需要访问数据库，需要对数据库内部的用户进行映射。用户是数据库级别的安全主体，访问数据库资源是授予给用户，而不是登录名。

2014-09-01 11:10:46 8211

翻译 Chapter 2 User Authentication, Authorization, and Security（7）：创建和使用用户自定义服务器角色

从SQL Server 2012开始，不再限制于使用固定服务器角色，可以创建自定义的角色，允许你预设特殊权限。

2014-09-01 11:03:35 4572

翻译 Chapter 2 User Authentication, Authorization, and Security（6）：服务器权限授予粒度

在SQL Server 2005之前，只有通过添加登录到固定服务器角色，才能获取管理权限。SQL Server 2005引入了一套服务器粒度权限，允许你定义一套严密的权限给服务器级别的登录。

2014-09-01 11:01:04 4549

翻译 Chapter 2 User Authentication, Authorization, and Security（5）：使用固定服务器角色

登录帐号允许你连到SQL Server，并且如果有数据库用户映射到这个帐号，那么这个帐号也可以访问对应的数据库。默认情况下，他们没有服务器层面的管理操作权。固定服务器角色允许你简化授权和回收权限的操作。

2014-09-01 11:00:14 4805

翻译 Chapter 2 User Authentication, Authorization, and Security（4）：限制SA帐号的管理权限

SA帐号是SQL Server的系统管理员，在安装过程中就可以启用，在SQL Server 2005之前，这个帐号不能修改，但是从2005开始，可以重命名或者禁用sa来减少被攻击的风险。在后续版本中，Sa仅作为向后兼容。由于SA是众人皆知的帐号，不建议使用。

2014-08-25 11:07:36 5242 1

翻译 Chapter 2 User Authentication, Authorization, and Security（3）：保护服务器避免暴力攻击

暴力攻击（Brute-force attack）是通过几乎所有可能的字符组合尝试破解密码，或者使用一个字典表，包含几乎所有可能的密码来实现密码破解的方法。如果你的密码很简单，那么很快就会被破解。所以，测试密码是非常重要的。

2014-08-22 14:41:42 5095

翻译 Chapter 2 User Authentication, Authorization, and Security（2）：创建登录帐号

登录帐号是定义在服务器（实例）级别，并能被授予进行管理任务、连接、访问数据库等权限的帐号。SQL Server安全模型有两个级别：服务器级别和数据库级别。登录帐号必须先创建在服务器级别。如果需要访问数据库，还需要在数据库级别创建一个用户映射到已有的登录名中。

2014-08-20 14:41:04 7327

翻译 Chapter 2 User Authentication, Authorization, and Security（1）：选择Windows和SQL 身份验证

SQL Server 有两种身份验证：一种是WIndows身份验证，Windows身份验证使用Windows上的帐号，并利用其安全令牌进行验证。一种是SQL Server验证，使用SQL Server里面定义的帐号进行身份验证。

2014-08-18 11:13:41 5896

翻译 Chapter 1 Securing Your Server and Network(14):限制功能——xp_cmdshell 和OPENROWSET

基于安全性原因，某些功能在安装SQL Server时就被禁用，从2008开始，所有敏感选项可以通过一个叫【外围应用配置器】的【方面】进行管理，这个功能在2005的时候以独立工具的形式出现过，在2008又取消了。

2014-08-18 11:09:21 5078

翻译 Chapter 1 Securing Your Server and Network(13):配置端点安全性

SQL Server端点（Endpoint）是出入SQL Server的门户，通过端点，任何东西可以在网络和SQL Server之间传输。端点可以是系统或者用户自定义的，其中系统端点允许使用T-SQL连接SQL Server并发送查询。

2014-08-11 11:32:15 4651

翻译 Chapter 1 Securing Your Server and Network(12):保护链接服务器

链接服务器（Linked Server）可以使两个不同的SQL Server实例甚至和其他类型的RDBMS进行互访。通过链接服务器，可以实现分布式查询，类似于一个应用程序，把连接目标服务器的连接字符串预存起来。

2014-08-08 13:53:40 4456

翻译 Chapter 1 Securing Your Server and Network(11):使用透明数据库加密

如果没有对数据库文件（MDF/LDF等）做权限控制，攻击者可以把这些文件复制走，然后附加到自己机器上进行分析。第一层保护就是对SQL Server文件所在的NTFS文件系统进行权限管控。如果希望进一步保护数据库，可以使用透明数据库加密（Transparent Database Encryption,TDE），这个功能可以保护对应数据库的所有文件，不管有多少个文件。因为文件已经加密，即使这些文件被复制走，如果没有数据库主密钥，也一样不能使用。同时，这种加密不影响用户对数据库的使用，开发人员不需要对此做额外的工

2014-08-06 11:49:25 4626

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

Test file 123

Tectia client

make_big_adventure.sql

Windows性能计数器列表

Microsoft Big Data Solutions

SQLServer安全性文档

使用DMV对SQLServer进行性能调优

数据库对比工具ASQLDiff

AdventureWorks2012

Inside Microsoft SQL Server 2008:T-SQL Querying

Microsoft SQL Server 2005技术内幕：T-SQL查询

RedGate.SQL.Prompt.v.5.1.8.2

SQL编程风格

SQLServer2008企业级平台管理实践01

SQLServer2008企业级平台管理实践02

SQL.Server.DMVs.实战

SQL Server 2005 Administrator's Companion

Microsoft SQL Server 2005技术内幕：T-SQL查询.02

Microsoft SQL Server 2005技术内幕：T-SQL查询.01

Microsoft SQL Server 2005技术内幕： T-SQ程序设计.01

Microsoft SQL Server 2005技术内幕： T-SQ程序设计.02

Microsoft SQL Server 2005技术内幕.存储引擎

空空如也