笑东风

摘要： 修改资源访问顺序，使多个事务对资源的访问方式一致 优化查询SELECT，使得S锁能尽早释放 均可能将更新和删除语句放到事务末端(使得X锁占用时间最小) 避免事务执行期间暂停或等待外部输入 将较大事务拆分成多个小事务提交 控制事务在合适的隔离级别上运行 建立合适索引提示语句效率 删除无用索引和统计 将数据更新修改为数据插入 将数据拆按状态分到多个表 考虑使用快照解决S锁阻塞X锁 考虑使用程序队列来限制并发数（高并发造成大量的锁等待和上下文切换以及CPU资源消耗） 使用复制等技术将读写分离 在程序段使用缓存来避免对相同数据频繁更新 阅读全文

摘要： 存在这样情况： 1.表TB1有一列建立索引 2.事务A对表进行更新，先获取对表的X锁以更新基本表中数据，然后对索引申请X锁以更新索引数据。 3.事务B对表进行更新，先获取索引上S锁以使用索引进行Loopup来查询数据，然后申请表的X锁以更新基本表数据 由于事务A和事务B申请到一部分锁资源同时需要对方的锁资源来完成操作，由于锁的不可剥夺性导致死锁产生 解决此类死锁的有效办法： 1.减少每次修改数据的行数,以减少事务的执行时间，从而降低事务发生的可能性 2.在一些情况下使用Include索引来减少lookup操作 阅读全文

摘要： 死锁发生情况：1. 存在表A和表B，表A的主键是表B的外键2.事务A在表A上申请到X锁以修改表A中数据和删除表A中的数据，然后需要检查表B中的数据是否满足外键约束，从而需要Range锁来锁住表B3.事务B在表B上申请到X锁以修改表B中数据，然后向表A申请S锁来查询数据以上情况表造成资源环状阻塞，从而应发死锁。解决办法：1. 从设计角度来看，应避免修改表A中主键的值2. 对表B上的外键列建立索引，从而使事务A发生时将range锁放到索引上，从而降低死锁发生的概率​ 阅读全文

摘要： 一个很小的CDC Demo和相关操作 阅读全文

摘要： 在事务中使用TRY CATCH的一些基础 阅读全文

摘要： 一个存储过程中使用事务的模板 阅读全文

摘要： 在TSQL中，如果需要判断当前错误是否是因为死锁引起，可以使用ERROR_NUMBER()=1205来判断 在C#中，使用SQLException来捕获 SQLException.Number=1205代表由死锁引发 使用跟踪标记来查看死锁 1204 返回参与死锁的锁的资源和类型，以及受影响的当前命令。作用域：仅全局 1222 以不符合任何XSD 架构的XML 格式，返回参与死锁的锁的资源和类型，以及受影响的当前命令 阅读全文

摘要： 在事务执行过程中，并不保证两次读取数据一致，当数据在其他事务中修改并提交，再次查询能立即得到最新的数据。 使用快照来保存修改数据的原始版本，读取数据时如数据已经被修改但为提交，则读取快照中的副本数据 --===================================================== 在开启行版本控制后，SQL SERVER 会将行版本数据存放tempdb里，需要考虑tempdb的负载 --===================================================== 优点：有效减少读和写得阻塞,不会读取过时数据和不会引发数据版本冲突 缺点：维护行版本需要额外的开销 阅读全文

摘要： 一些需求要求两次查询数据之间不允许数据被修改，即可重复读取可重复读REPEATABLE READ与串行化SERIALIZABLE的区别在于串行化要求满足该查询的数据不被修改且无新满足该查询条件的数据插入（使用范围锁），可重复读只要求数据不被修改（保留S锁至事务结束）。而在read commit事务隔离级别下，被更新的数据会被加S锁，并一直保持事务提交或回滚，因此数据在事务区间内不能被其他事务修改，也保证了两次查询得到数据不发生变化(数据的值而不是行数)因此我们可以使用几种方式来保持数据不发生变化：方式1：在提交读隔离级别下使用HOLDLOCKHOLDLOCK相当于SERIALIZABLE隔离级 阅读全文

摘要： 在很多编程语言中，可以实现嵌套，但在TSQL中，可以实现嵌套事务吗？ 答案：不可以 阅读全文

摘要： 事务中使用return会回滚事务吗？ 答案：不会，如果在事务中没有显示提交或回滚事务边return，事务不会被提交或回滚，在C#中，如果没有使用连接池，则事务在连接断开和销毁时被强制回滚，如果使用连接池，则事务在连接被再次使用时调用的exec sp_reset_connection存储过程清理掉。如果该连接没有被再次使用或删除，则事务一直存在，便会一直锁住相关资源不释放，照常日志变大，镜像和复制异常等情况。 阅读全文

摘要： SQL SERVER 事务隔离级别：1.未提交读(READ UNCOMMITED) 允许脏读，读取数据时不加共享锁，与使用WITH(NOLOCK)结果相同2.已提交读 不允许脏读，读取数据时加共享锁，但在查询结束后立即释放共享锁，而不用等到事务结束3.可重复读 不允许“不可重复读”，读取数据时加共享锁，将共享锁一直保持到事务结束，从而阻塞其他事务修改被读取的数据4.快照 SQL SERVER 有两种行版本控制,在事务修改数据时，保留一份未修改前的数据副本，其他事务读取数据时访问副本数据，从而有效较少读和写的阻塞 a)已提交读快照隔离(READ_COMMITED_SNAPSHOT) b)SNAP 阅读全文

摘要： 常用的查询事务和锁的语句 阅读全文

摘要： 在快照隔离级别下，在事务执行过程中，数据已被外部事务修改并且提交，但查询会得到过时数据(取决于生成快照的第一次时间点在外部事物发生前还是发生后)，对过时数据修改会报以下错误： 快照隔离事务由于更新冲突而中止。您无法在数据库'DB5'中使用快照隔离来直接或间接访问表 'dbo.TB1'，以便更新、删除或插入已由其他事务修改或删除的行。请重试该事务或更改 update/delete 语句的隔离级别。 阅读全文

摘要： --====================================================--查看数据库备份的详细信息：时间存储地址最大/最小LSNSELECT * FROM msdb.dbo.backupset AS BSINNER JOIN msdb.dbo.backupfile AS BFON BF.backup_set_id=BS.backup_set_idINNER JOIN msdb.dbo.backupmediaset AS BMSON BMS.media_set_id=BS.media_set_idINNER JOIN msdb.dbo.backupmedia 阅读全文

摘要： -- Recovery model, log reuse wait description, log file size,-- log usage size and compatibility level for all databases on instanceSELECTdb.[name] AS [Database Name] ,db.recovery_model_desc AS [Recovery Model] ,db.log_reuse_wait_desc AS [Log Reuse Wait Description] ,ls.cntr_value AS [Log Size (KB)] 阅读全文

摘要： 1. 有产生大日志操作，如重建整理索引，大量数据修改等2. 长期未提交事务，为保证为提交事务可以回滚，从最早为提交事务开始之后的所有事务，都是活动事务，不能被截断或覆盖3. 日志没有定期备份4. 镜像或复制需要读取但还未读取的日志会被保留，镜像或复制出现错误时，会导致日志无法截断5. 检查点的执行频率过低（被人为修改）6. 用户打开游标但为及时取走数据并关闭右边查看当前日志不能截断的原因SELECT name,DB.log_reuse_wait_desc FROM sys.databases DB​事务日志空间的重用操作当前正在等待下列各项之一：0 = 无1 = 检查点2 = 日志备份3 = 阅读全文

摘要： 数据库日志相关的一下小知识点 阅读全文

摘要： 字符集一些相关技巧 阅读全文

摘要： 获取中文首字母拼音 阅读全文