2013年12月1日
摘要：
摘要：一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。关 于数据库优化方面的文章很多，但是有的写的似是而非，有的不切实际，对一个数据库来说，只能做到更优，不可能最优，并且由于实际需求不同，优化方案还是有 所差异，根据实际需要关心的方面（速度、存储空间、可维护性、可拓展性）来优化数据库，而这些方面往往又是相互矛盾的，下面结合网上的一些看法和自己的一 些观点做个总结。 一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优，也不单单是开发阶段的事情.. 阅读全文
摘要：
数据库中的数据编辑是我们遇到的最频繁的工作，这一个随笔中我来总结一下最常用的数据编辑。 select into 经常遇到一种情况是，我们希望创建一个新表，表中的数据来源于原有的一个表；原有一个表，但是这个表中的数据已经很混乱，我们希望把这些数据备份出来，然后把原有的表中的数据清除，重新导入；在这些情况下我们可以使用select into语句。 如果当前用户拥有建表权限，在select语句使用关键字into可以在数据库中创建新的 表。这个语句只需要把into new_table_name加到选择出的列名之后，from关键字之前，当然数据可以来源于一个或多个表中。需要说明的是在新表中只包... 阅读全文
摘要：
在大中型项目中，在数据库设计的时候，考虑到数据库最大承受数据量，通常会把数据库或者数据表水平切分，以降低单个库，单个表的压 力。我这里介绍两个我们项目中常用的数据表切分方法。当然这些方法都是在程序中使用一定的技巧来路由到具体的表的。首先我们要确认根据什么来水平切分？ 在我们的系统（SNS）中，用户的UID贯穿系统，唯一自增长，根据这个字段分表，再好不过。 方法一：使用MD5哈希 做法是对UID进行md5加密，然后取前几位（我们这里取前两位），然后就可以将不同的UID哈希到不同的用户表（user_xx）中了。function getTable( $uid ){ $ext=substr ... 阅读全文
摘要：
三大范式: 第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，因而减少了数据冗余，也利于性能的提高。 完全按照三大范式规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化... 阅读全文
摘要：
摘要：本来是打算先写SQLServer历史的，不过感觉写那部分内容比较难还需要多查些资料。于是调整了下顺序写下简单的Insert语句。 不过感觉写那部分内容比较难还需要多查些资料。于是调整了下顺序写下简单的Insert语句。数据库结构还是采用上一篇的结构。具体查看上一篇文章《擦亮自己的眼睛去看SQL Server之简单Select》。今天讨论的语句也比较简单，Insert语句。 一、Insert脚本 insertinto Test([Name]) values('xiaojun') 没什么好说的，因为想写这样的语句太简单。 二、 语句分析 这条语句到底发生了什么呢？假... 阅读全文
摘要：
摘要：这篇文章主要和大家讨论几乎所有人都熟悉，但不少人又陌生的一条select语句。 这篇文章主要和大家讨论几乎所有人都熟悉，但不少人又陌生的一条select语句。不知道大家有没有想过到底是什么东西让SQL Server能理解我们写的select。这中间到底发生了什么，是不是有过冲动想去了解。至少我曾经冲动想去了解，但当时主要在研究CLR以及 WebForm相关知识。后来主要精力放在研究SQL Server内部机制，今天就给大家介绍下这条语句。 一、范例数据库脚本 createdatabase Test go alterdatabase Test set recovery simple... 阅读全文
摘要：
虽然查询速度慢的原因很多，但是如果通过一定的优化，也可以使查询问题得到一定程度的解决。 查询速度慢的原因很多，常见如下几种：没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)I/O吞吐量小，形成了瓶颈效应。没有创建计算列导致查询不优化。内存不足网络速度慢查询出的数据量过大(可以采用多次查询，其他的方法降低数据量)锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)sp_lock, sp_who, 活动的用户查看，原因是读写竞争资源。返回了不必要的行和列查询语句不好，没有优化 可以通过如下方法来优化查询 :把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可... 阅读全文
摘要：
最近公司来一个非常虎的DBA，10几年的经验，这里就称之为蔡老师吧，在征得我们蔡老同意的前提下 ，我们来分享一下蔡老给我们带来的宝贵财富，欢迎其他的DBA来拍砖。目录1、什么是执行计划？执行计划是依赖于什么信息2、 统一SQL语句的写法减少解析开销3、 减少SQL语句的嵌套4、 使用“临时表”暂存中间结果5、 OLTP系统SQL语句必须采用绑定变量6、 倾斜字段的绑定变量窥测问题7、 begin tran的事务要尽量地小8、 一些SQL查询语句应加上nolock9、加nolock后查询经常发生页分裂的表，容易产生跳读或重复读10、聚集索引没有建在表的顺序字段上，该表容易发生页分裂11、使用复合 阅读全文
摘要：
一、理解索引的结构 索引在数据库中的作用类似于目录在书籍中的作用，用来提高查找信息的速度。使用索引查找数据，无需对整表进行扫描，可以快速找到所需数据。微软 的SQL SERVER提供了两种索引：聚集索引（clustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）。 SQL Server 中数据存储的基本单位是页（Page）。数据库中的数据文件（.mdf 或 .ndf）分配的磁盘空间可以从逻辑上划分成页（从 0 到 n 连续编号）。磁盘 I/O 操作在页级执行。也就是说，SQL Server 每次读取或写入数据... 阅读全文
摘要：
1. 在生产环境中不要出现Select * 这一点我想大家已经是比较熟知了，这样的错误相信会犯的人不会太多。但我这里还是要说一下。 不使用Select *的原因主要不是坊间所流传的将*解析成具体的列需要产生消耗，这点消耗在我看来完全可以忽略不计。更主要的原因来自以下两点:扩展方面的问题造成额外的书签查找或是由查找变为扫描 扩展方面的问题是当表中添加一个列时，Select *会把这一列也囊括进去，从而造成上面的第二种问题。 而额外的IO这点显而易见，当查找不需要的列时自然会产生不必要的IO，下面我们通过一个非常简单的例子来比较这两种差别，如图1所示。图1.*带来的不必要的IO 2. 声... 阅读全文