00 – 背景知识 - B-Tree & B+Tree http://en.wikipedia.org/wiki/B%2B_tree http://en.wikipedia.org/wiki/B-tree - 折半查找(Binary Search) http://en.wikipedia.org/wiki/Binary_search_algorithm - 数据库的性能问题 A. 磁盘IO性能非常低，严重的影响数据库系统的性能。 B. 磁盘顺序读写比随机读写的性能高很多。 - 数据的基本存储结构 A. 磁盘空间被划分为许多大小相同的块（Block）或者页(Page). B. 一个表的这些数据块以链表的方式串联在一起。 C. 数据是以行（Row）为单位一行一行的存放在磁盘上的块中,如图所示. D. 在访问数据时，一次从磁盘中读出或者写入至少一个完整的Block。
Browsing the archives for the mysql tag
浅谈伪分布式数据库架构
示意图： 在使用MySQL的应用中，如果你的MySQL Server压力逐渐增大，在应用层优化已经到了一定瓶颈时，那么你应该首先考虑MySQL_Replication。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。 如何同步 主库将所有的更新操作，写入二进制日志。 从库运行"IO线程"（Slave IO Thread）读取主库的二进制日志。 从库运行"SQL线程"（Slave SQL Thread）执行IO线程（Slave IO Thread）读取的日志中的SQL,从而保持和主库的一致。 如何分配请求 目前，这部分需要在应用层实现。 执行更新SQL(UPDATE，INSERT，DELETE)时，请求主库。 执行查询SQL(SELECT)时，请求从库。 所以，当你的应用(Application)SELECT请求所占的比率越大，那么Relication就会越有效。 相关教程: MySQL传输二进制日志原理:http://blog.haohtml.com/archives/12094
摘自:http://www.orczhou.com/index.php/2011/11/how-mysql-send-the-binary-log/ MySQL Replication可以很方便的用来做应用的读扩展，也可以帮MySQL实现一定程度的HA方案。MySQL通过向备库传送二进制日志来实现Replication，本文将通过二进制日志相关源代码的主要接口来解释：“MySQL如何传输二进制日志，是主库推，还是备库拉？MySQL日志传输的实时性如何？”。 在MySQL Replication结构中，备库端初次通过CHANGE MASTER TO完成Replication配置，再使用start slave命令开始复制。更细致的，备库通过IO Thread向主库发起读取binlog的请求（COM_BINLOG_DUMP命令），主库收到COM_BINLOG_DUMP请求后，使用单独线程（dump thread）不断向备库IO Thread发送Binlog。示意图：
在平时被问及最多的问题就是关于 MySQL 数据库性能优化方面的问题，所以最近打算写一个MySQL数据库性能优化方面的系列文章，希望对初中级 MySQL DBA 以及其他对 MySQL 性能优化感兴趣的朋友们有所帮助。 这是本系列的第一篇文章：MySQL 数据库性能优化之缓存参数优化 数据库属于 IO 密集型的应用程序，其主要职责就是数据的管理及存储工作。而我们知道，从内存中读取一个数据库的时间是微秒级别，而从一块普通硬盘上读取一个IO是在毫秒级别，二者相差3个数量级。所以，要优化数据库，首先第一步需要优化的就是 IO，尽可能将磁盘IO转化为内存IO。本文先从 MySQL 数据库IO相关参数（缓存参数）的角度来看看可以通过哪些参数进行IO优化： query_cache_size/query_cache_type （global） Query cache 作用于整个 MySQL Instance，主要用来缓存 MySQL 中的 ResultSet，也就是一条SQL语句执行的结果集，所以仅仅只能针对select语句。当我们打开了 Query Cache 功能，MySQL在接受到一条select语句的请求后，如果该语句满足Query Cache的要求（未显式说明不允许使用Query Cache，或者已经显式申明需要使用Query Cache），MySQL 会直接根据预先设定好的HASH算法将接受到的select语句以字符串方式进行hash，然后到Query Cache 中直接查找是否已经缓存。也就是说，如果已经在缓存中，该select请求就会直接将数据返回，从而省略了后面所有的步骤（如 SQL语句的解析，优化器优化以及向存储引擎请求数据等），极大的提高性能。
官方教程：http://dev.mysql.com/doc/refman/5.1/zh/storage-engines.html#innodb 3.6 InnoDB存储引擎文件 之前介绍的文件都是MySQL数据库本身的文件，和存储引擎无关。除了这些文件外，每个表存储引擎还有其自己独有的文件。这一节将具体介绍和InnoDB存储引擎密切相关的文件，这些文件包括重做日志文件、表空间文件。 3.6.1 表空间文件 InnoDB存储引擎在存储设计上模仿了Oracle，将存储的数据按表空间进行存放。默认配置下，会有一个初始化大小为10MB、名为ibdata1的文件。该文件就是默认的表空间文件（tablespace file）。你可以通过参数innodb_data_file_path对其进行设置。格式如下： innodb_data_file_path=datafile_spec1[;datafile_spec2]... 你也可以用多个文件组成一个表空间，同时制定文件的属性，如：
作/译者：叶金荣（Email: ），来源：http://imysql.cn，转载请注明作/译者和出处，并且不能用于商业用途，违者必究。 并不是所有MySQL都运行在Linux下，windows下也需要做例行备份，下面是用bat脚本做自动化备份的例子，大家可以参考下。 rem rem C:\Program Files\WinRAR 需要放到 path 下，才能调用rar cli工具 rem rem 跳转到工作目录下 f: cd f:\DBBAK rem 设置变量：备份文件名 SET BAK_FILE=MY_DBBAK_%date:~0,-4%.sql rem 设置变量：日志文件名 SET LOG_FILE=MY_DBBAK.log rem 记录日志 echo "%date%" >> %LOG_FILE% rem 开始做备份 mysqldump --default-character-set=utf8 -hlocalhost -uroot -R --triggers --single-transaction -B mydb > %BAK_FILE% rem 压缩备份文件 rar a %BAK_FILE%.rar %BAK_FILE% rem 删除源文件 del /F %BAK_FILE% echo [...]
在执行查询的时候,有时候用show processlist命令查看有过多的进程,造成mysql假死的状态,这个时候可以将一些僵死的进程杀掉.恢复正常状态 找到语句的 thread id mysqladmin -uroot -proot kill xxxxx 如果是系统里的mysql进程的话,可以参考:http://www.chengyongxu.com/blog/%E6%89%B9%E9%87%8F%E6%9D%80%E6%AD%BBmysql%E8%BF%9B%E7%A8%8B/
1.修改root用户口令，删除空口令 2.删除默认数据库和数据库用户 3.改变默认mysql管理员帐号 4.关于密码的管理 5.使用独立用户运行msyql 6.禁止远程连接数据库 7.限制连接用户的数量 8.用户目录权限限制 9.命令历史记录保护 10.禁止MySQL对本地文件存取 11.MySQL服务器权限控制 12.使用chroot方式来控制MySQL的运行目录 13.关闭对无关的Web程序访问的支持 14.数据库备份策略 15. Mysqld安全相关启动选项 16.information_schema 安全 1.修改root用户口令，删除空口令 缺省安装的MySQL的root用户是空密码的，为了安全起见，必须修改为强密码，所谓的强密码，至少8位，由字母、数字和符号组成的不规律密码。使用MySQL自带的命令mysaladmin修改root密码，同时也可以登陆数据库，修改数据库mysql下的user表的字段内容，修改方法如下所示： # /usr/local/mysql/bin/mysqladmin -u root password “upassword” //使用mysqladmin #mysql> use mysql; #mysql> update user set password=password(‘upassword’) where user=’root’; #mysql> flush privileges; //强制刷新内存授权表，否则用的还是在内存缓冲的口令 2.删除默认数据库和数据库用户 一般情况下，MySQL数据库安装在本地，并且也只需要本地的php脚本对mysql进行读取，所以很多用户不需要，尤其是默认安装的用户。MySQL初始化后会自动生成空用户和test库，进行安装的测试，这会对数据库的安全构成威胁，有必要全部删除，最后的状态只保留单个root即可，当然以后根据需要增加用户和数据库。
Facebook的用户每天创造大量的数据，为了确保数据可靠的存储，我们每天进行数据备份.我们通过将原来的逻辑备份改成定制化的物理备份,显著地提升了备份的速度(不增加体积的情况下). 从mysqldump到Xtrabackup 我们使用mysqldump来进行每日的数据库备份,mysqldump对数据进行逻辑备份,就像应用访问数据库那样,mysqldump以SQL语句的方式从数据库中读取一张张表,将表结构和数据转保存到文本文件.mysqldump最大的问题是速度太慢(对于我们的一些大的数据库,通常要花24小时,甚至更久),并且以SQL语句的方式读取数据可能造成磁盘的随机读,这就会造成主机的load增大,影响性能.对于时间太长,我们可以跑多个实例来并发的做备份,这能缩短备份的时间,但是会造成更多的load,更影响主机的性能. 另外一个可行的备份方式是进行物理备份(我们称之为二进制备份,binary backup),通过操作系统层面,读取数据库磁盘文件,而非通过SQL语句.这样的话在备份的过程中,数据不能像SQL读取的时候保持事务上一致的.只有当备份的数据文件在数据库里复原了,他们才又一致了,这类似于数据库down掉之重启一样. 我们通过修改增强Xtrabackup来满足我们额外的需求: 1.支持快速的表级还原 2.增强全量和增量备份 3.支持混合增量备份 Xtrabackup支持增量备份,也就是备份自上次全量备份后改变的数据.这样我们就能够减少备份的空间(比如每天一次增量备份,每周一次全量备份).Xtrabackup也支持多级增量备份,不过我们不使用,避免复杂.
