yingfeng2oo8的专栏

随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台机器的访问负载，降低了宕机

最近因为项目原因一直在研究分表、分库和读写分离。本来打算直接使用一款开源产品，但作者只开源了一部分，无奈只好自己动手丰衣足食了。分库、分表常用策略：1.平均进行分配。2.按照权重进行分配且均匀轮询。3.按照业务进行分配。4.按照一致性hash算法进行分配。分表又分为单库分表（表名不同）和多库分表（表名相同），不管使用哪种策略都还需要使用路由技术。读写分离

讨人喜欢的 MySQL replace into 用法（insert into 的增强版）在向表中插入数据的时候，经常遇到这样的情况：1. 首先判断数据是否存在； 2. 如果不存在，则插入；3.如果存在，则更新。在 SQL Server 中可以这样处理： if not exists (select 1 from t where id = 1) insert in

MySQL 对 SQL 有很多扩展，有些用起来很方便，但有一些被误用之后会有性能问题，还会有一些意料之外的副作用，比如 REPLACE INTO。比如有这样一张表：12345678CREATE TABLE `auto` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `k` i

如果在INSERT语句末尾指定了ON DUPLICATE KEY UPDATE，并且插入行后会导致在一个UNIQUE索引或PRIMARY KEY中出现重复值，则执行旧行UPDATE；如果不会导致唯一值列重复的问题，则插入新行。例如，如果列a被定义为UNIQUE，并且包含值1，则以下 两个语句具有相同的效果：1234INSERT INTO TABLE (a

最近再找一些Mysql锁表原因，整理出来一部分sql语句会锁表的，方便查阅，整理的不是很全，都是工作中碰到的，会持续更新笔者能力有限，如果有不正确的，或者不到位的地方，还请大家指出来，方便你我，方便大家。此测试环境Mysql 5.5 基于innodb 引擎[sql] view plaincopyinse

以下分享一点我的经验 一般刚开始学SQL的时候，会这样写 复制代码代码如下:SELECT * FROM table ORDER BY id LIMIT 1000, 10; 但在数据达到百万级的时候，这样写会慢死 复制代码代码如下:SELECT * FROM table ORDER BY id LIMIT 1000000, 10; 

线上某服务时不时报出如下异常（大约一天二十多次）：“Deadlock found when trying to get lock;”。      Oh, My God! 是死锁问题。尽管报错不多，对性能目前看来也无太大影响，但还是需要解决，保不齐哪天成为性能瓶颈。     为了更系统的分析问题，本文将从死锁检测、索引隔离级别与锁的关系、死锁成因、问题定位这五个方面来展开讨论。

上一篇文章《MySQL悲观锁总结和实践》谈到了MySQL悲观锁，但是悲观锁并不是适用于任何场景，它也有它存在的一些不足，因为悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。如果加锁的时间过长，其他用户长时间无法访问，影响了程序的并发访问性，同时这样对数据库性能开销影响也很大，特别是对长事务而言，这样的开销往往无法承受。所以与悲观锁相对的，我们有了乐观锁，具体参见下面介绍：

造成死锁的原因就是多个线程或进程对同一个资源的争抢或相互依赖。这里列举一个对同一个资源的争抢造成死锁的实例。Oracle 10g, PL/SQL version 9.2[sql] view plain copyCREATE TABLE testLock(  ID NUMBER,  test VARCHAR(100)  )  C

[sql] view plain copyEXP-00091: 正在导出有问题的统计信息。  . . 正在导出表                      WF_GENERAL导出了  EXP-00091: 正在导出有问题的统计信息。  . . 正在导出表                    WF_PLAN_BOOK导出了  EXP-00091: 

先上问题！    现在有A、B、C三张表，A和B是一对多的关系，B和C是一对一的关系，C和B是一对多的关系，A和C是多对多的关系。问题：是否设计第四张表专门存放A、B、C的关系，还是把关系维护在B表中？原则：首先在数据库中不建议建立三维关系。其实就是说一张表（关系表）不要维系三个模型的的关系设计思路：

1)不可重复读是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取

1

随着大型互联网应用的发展，海量数据的存储和访问成为系统设计的瓶颈，分布式处理成为不二选择。数据库拆分，特别是水平分库是个高难度的活，涉及一系列技术决策。本人有幸负责1号店订单水平分库的方案设计及实施落地，这里结合项目实践，对水平分库做一个系统地剖析，希望为大家水平分库(包括去IOE)改造提供思路，主要内容包括：水平分库说明分库维度– 根据哪个字段分库分库策略– 记录如何分配到不同库

这是我的一个综合评分，总共分为12个单项，每个单项最高5分，最低0分。注意，评价只包含这些软件提供的标准功能，不包含第三方提供的功能，如代码生成等。开发效率hibernate  能获取数据库metadata，因此简单的sql操作，如插入，更新，删除，翻页等，都可以自动完成。但因为概念复杂，经常会导致开发人员会写sql，能写java，但不会写hibernate情况出现

先说一个笑话，作为开场白。俺也换换风格试一试，呵呵。　　在以前，有三个书生赶考，在路上遇到了一个算命先生，于是就问算命先生：我们三个人赶考，结果如何呀？算命先生伸出来了一个手指头（食指）。三个书生赶考的结果是，有一个人考中了。三人一想呀，这个挂算的对呀，有一个人考中了嘛。　　其实“一个手指头”是很模糊的，很忽悠人的。有各种各样的解释，比如：一个人考中；一个人没考中；一起考中了；

面向程序员的数据库访问性能优化法则 特别说明：1、  本文只是面对数据库应用开发的程序员，不适合专业DBA，DBA在数据库性能优化方面需要了解更多的知识；2、  本文许多示例及概念是基于Oracle数据库描述，对于其它关系型数据库也可以参考，但许多观点不适合于KV数据库或内存数据库或者是基于SSD技术的数据库；3、  本文未深入数据库优化中最核心的执行计划分析技术。 读

并发与数据读取当多个会话同时访问（操作）相同的数据时，将会出现一些意想不到的结果，这包括：– 脏读 -- Dirty reads– 不可重复度-- Non-repeatable reads– 幻读 -- Phantom reads1、脏读脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，

最近学习了一下数据库的悲观锁和乐观锁，根据自己的理解和网上参考资料总结如下： 悲观锁介绍（百科）：悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制