IT民工

----   人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略 了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库 环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。笔者在工作实践 中发现，不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的whe re子句。在对它们进行适当的优化后，其运行速度

1：索引，我们最先想到的就是创建索引，创建索引可以成倍的提升查询的效率，节省时间。但是如果数据量太过于巨大的时候，这个时候单纯的创建索引是无济于事的，我们知道假如特别是在大数据量中统计查询，就拿1000W数据来说吧，如果使用count函数的话，最少要50-100秒以上，当然如果你的服务器配置够高，处理够快，或许会少很多但是一样会超过10秒。 单纯的建立索引是无济于事的。我们可以在创建索引的时候

/****** 对象: 存储过程 dbo.get_zb_count 脚本日期: 2007-05-18 15:34:33 ******/ CREATE PROCEDURE get_zb_count_3 @J_JID varchar(50), @S_Area varchar(6000), @K_ID varchar(50), @zb_count int output

drop procedure if exists pro_rep_shadow_rs; delimiter | ---------------------------------- -- rep_shadow_rs -- 用来处理信息的增加，更新和删除 -- 每次只更新上次以来没有做过的数据 -- 根据不同的标志位 -- 需要一个输出的参数， -- 如果返回为0，则

GO TO TOP1） 使用 ReadOnly 属性摇∪绻Ｍ珼ataGridView 内所有单元格都不可编辑， 那么只要： [VB.NET] ' 设置 DataGridView1 为只读 DataGridView1.ReadOnly = True[C#]// 设置 DataGridView1 为只读DataGridView1.ReadOnly = true;

在SQL Server中，除了系统数据库外，你创建的每一个数据库都有三种可供选择的恢复模式: Simple(简单), full(完整), bulk-logged(批量日志)。 下面这条语句可以显示出所有在线数据库的恢复模式:SELECT name, (SELECT DATABASEPROPERTYEX(name, 'RECOVERY')) RecoveryModel FROM master..

在某些偶然的情况下，会引起SQL Server 2005数据库日志文件的损坏，比如：硬件故障、计算机非正常重启或关机。当SQL Server 2005数据库日志文件损坏时，可能会出现以下情况：1、在SQL Server Management Studio中显示数据库处于置疑(suspect)状态。2、事件日志可能会出现如下错误信息：   Could not redo log rec