zbuger的博客

mysql数据库的事务隔离级别相信很多同学都知道.大家有没有想过它是如何实现的呢?带着这些问题我翻阅了相关数据库的书籍和资料,把我的理解写下来.一：事务隔离级别mysql数据库的隔离界别如下:1, READ UNCOMMITTED(未提交读)事务中的修改,即使没有提交,对其它事务也是可见的.  脏读(Dirty Read).2, READ

事务就是一个会话过程中，对上下文的影响是一致的，要么所有的更改都做了，要么所有的更变都撤销掉。就要么生，要么死。没有半死不死的中间不可预期状态。参考下薛定谔的猫。事务是为了保障业务数据的完整性和准确性的。分布式事务，常见的两个处理办法就是两段式提交和补偿。两段式提交典型的就是XA，有个事务协调器，告诉大家，来都准备好提交，大家回复，都准备好了，然后协调器告诉

【摘要】本文谈及一些分布式系统的理论和思想，包括CAP、BASE、NWR等。并简单分析一些主流数据库分布式方案的利弊，以便我们在开发时更深入全面地进行思考、选择和设计。以下为正文：在讨论常见架构前，先简单了解下CAP理论：CAP是Consistency、Availablity和Partition-tolerance的缩写。分别指：一致性（Consistency）：每次读操作

这段时间，一直在总结电商系统的相关基础技术和架构，写了很多东西。但是还是发现一个很重要，很基础的方面没有讲到，那就是数据库读写分离的主从架构。可能发展到大型成熟的公司之后，主从架构已经落伍了，取而代之的是更加复杂的数据库集群。但是作为一个小型电商公司，数据库的主从架构应该是最基础的。任何大型的系统架构，都是不断演进的。主从架构便是数据库架构中，最基础的架构。所以研究完主从架构，也就能看懂更加复杂的

垂直拆分垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表通常我们按以下原则进行垂直拆分:把不常用的字段单独放在一张表;把text，blob等大字段拆分出来放在附表中;经常组合查询的列放在一张表中;垂直拆分更多时候就应该在数据表设计之初就执行的步骤，然后查询的时候用jion关键起来即可;水平拆分水平拆分是指数据表行的拆分，

网上关于SQL优化的教程很多，但是比较杂乱。近日有空整理了一下，写出来跟大家分享一下，其中有错误和不足的地方，还请大家纠正补充。这篇文章我花费了大量的时间查找资料、修改、排版，希望大家阅读之后，感觉好的话推荐给更多的人，让更多的人看到、纠正以及补充。 1.对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。2.

1.SQL语句优化1）应尽量避免在 where 子句中使用!=或2）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num=03

Explain命令在解决数据库性能上是第一推荐使用命令，大部分的性能问题可以通过此命令来简单的解决，Explain可以用来查看SQL语句的执行效 果，可以帮助选择更好的索引和优化查询语句，写出更好的优化语句。Explain语法：explain select … from … [where ...]例如：explain select * from news;输出：+----+

一，游标是什么？                 游标是一段私有的SQL工作区,也就是一段内存区域,用于暂时存放受SQL语句影响到的数据。通俗理解就是将受影响的数据暂时放到了一个内存区域的虚表中，而这个虚表就是游标。        二，作用是什么？                  1，大家都知道数据库中的事物可以回滚，而游标在其中起着非常重要的作用，由于对数据

数据库范式是数据库设计中必不可少的知识，没有对范式的理解，就无法设计出高效率、优雅的数据库。甚至设计出错误的数据库。而想要理解并掌握范式却并不是那 么容易。教科书中一般以关系代数的方法来解释数据库范式。这样做虽然能够十分准确的表达数据库范式，但比较抽象，不太直观，不便于理解，更难以记忆。       本文用较为直白的语言介绍范式，旨在便于理解和记忆，这样做可能会出现一些不精确的表述。但对于

页级:引擎 BDB。表级:引擎 MyISAM ， 理解为锁住整个表，可以同时读，写不行行级:引擎 INNODB ， 单独的一行记录加锁表级，直接锁定整张表，在你锁定期间，其它进程无法对该表进行写操作。如果你是写锁，则其它进程则读也不允许行级,，仅对指定的记录进行加锁，这样其它进程还是可以对同一个表中的其它记录进行操作。页级，表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了

范式化设计目标的主要目的就是“减少不必要的更新”。但事事都具有两面性，在对数据库进行范式话设计的时候也不可避免的带来了一些副作用。一个完全范式化设计的数据库经常会面临“查询缓慢”这个问题。数据库越范式化，就需要Join越多的表。例如，把用户地址用独立的一张表来存储，在需要显示用户地址的时候就需要去join用户地址表。数据库的范式设计其中的一些优点可能并不这么值得称道:范式化节省了存

◆  简  介如果你对 “三范式” 不清楚，请点击这里（FQ）一步一步的了解什么是“三范式”。大家都说标准规范是重要的指导方针并且也这么做着，但是把它当作石头上的一块标记来记着（死记硬背）还是会带来麻烦的。以下 11 点是我在数据库设计时最优先考虑的规则。◆  规则 1：弄清楚将要开发的应用程序是什么性质的（OLTP 还是 OPAP）？当你要开始设计一个数据库的时候

在日常工作中，当我们遇到海量数据时，如何从中挑选出自己想要的数据呢？是盲目的查找，还是寻求新的解决方案亦或是通过技巧来获取？开发者在设计一个数据表单时，往往会遵循三条常用形式，他们认为常规模式是设计的唯一途径。然而由于开发者一开始就抱有这种心态，使数据表单设计变得墨守成规，阻碍了它的创新。Rule 1：弄清(OLTP或OLAP)应用的本质是什么？当开始制作数据表单设计时，首

MySQL InnoDB事务的隔离级别有四级，默认是“可重复读”（REPEATABLE READ）。未提交读（READ UNCOMMITTED）。另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据（脏读）。 提交读（READ COMMITTED）。本事务读取到的是最新的数据（其他事务提交后的）。问题是，在同一个事务里，前后两次相同的SELECT会读到不同的...

create database execise_new;use execise_new;-- 建表-- 学生表create table Student( s_id varchar(20), s_name varchar(20) not null default '', s_birth varchar(20) not null default '', s_sex...