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。

                   Fig. 1

01 – 数据基本操作的实现

基本操作包括：INSERT、UPDATE、DELETE、SELECT。

- SELECT

A. 定位数据
B. 读出数据所在的块，对数据加工
C. 返回数据给用户

- UPDATE、DELETE

A. 定位数据
B. 读出数据所在的块，修改数据
C. 写回磁盘

- INSERT

A. 定位数据要插入的页（如果数据需要排序）
B. 读出要插入的数据页，插入数据.
C. 写回磁盘

如何定位数据？
- 表扫描(Table Scan)

A. 从磁盘中依次读出所有的数据块，一行一行的进行数据匹配。
B. 时间复杂度 是O(n)， 如果所有的数据占用了100个块。尽管只查询一行数据，
也需要读出所有100个块的数据。
C. 需要大量的磁盘IO操作，极大的影响了数据定位的性能。

因为数据定位操作是所有数据操作必须的操作，数据定位操作的效率会直接影响所有的数据操作的效率。
因此我们开始思考，如何来减少磁盘的IO？
- 减少磁盘IO

A. 减少数据占用的磁盘空间
压缩算法、优化数据存储结构
B. 减少访问数据的总量
读出或写入的数据中，有一部分是数据操作所必须的，这部分称作有效数据。剩余的
部分则不是数据操作必须的数据，称为无效数据。例如，查询姓名是‘张三’的记录。
那么这条记录是有效记录，其他记录则是无效记录。我们要努力减少无效数据的访问。

02 – 索引的产生

- 键(Key)

首先，我们发现在多数情况下，定位操作并不需要匹配整行数据。而是很规律的只匹配某一个
或几个列的值。 例如，图中第1列就可以用来确定一条记录。这些用来确定一条数据的列，统
称为键(Key).

        Fig. 2

- Dense Index

根据减少无效数据访问的原则，我们将键的值拿过来存放到独立的块中。并且为每一个键值添
加一个指针， 指向原来的数据块。如图所示,

            Fig. 3

  这就是‘索引’的祖先Dense Index. 当进行定位操作时，不再进行表扫描。而是进行
  索引扫描(Index Scan)，依次读出所有的索引块，进行键值的匹配。当找到匹配的键值后，
根据该行的指针直接读取对应的数据块，进行操作。假设一个块中能存储100行数据，
10,000,000行的数据需要100,000个块的存储空间。假设键值列（+指针）占用一行数据
1/10的空间。那么大约需要10,000个块来存储Dense索引。因此我们用大约1/10的额外存储
空间换来了大约全表扫描10倍的定位效率。

03 – 索引的进化

  在实际的应用中，这样的定位效率仍然不能满足需求。很多人可能已经想到了，通过排序和查找
  算法来减少IO的访问。因此我们开始尝试对Dense Index进行排序存储,并且期望利用排序查
  找算法来减少磁盘IO。

- 折半块查找

A. 对Dense Index排序
B. 需要一个数组按顺序存储索引块地址。以块为单位，不存储所有的行的地址。
C. 这个索引块地址数组，也要存储到磁盘上。将其单独存放在一个或多个连续的块中，如下图所示。
D. 折半查找的时间复杂度是O(logN)。在上面的列子中，dense索引总共有10,000个块。假设1个块
能存储2000个指针，需要5个块来存储这个数组。通过折半查找，我们最多只需要读取
5（数组块）+100（索引块）+1（数据块）=106个块。

                    Fig. 4

- Sparse Index

实现基于块的折半查找时发现，读出每个块后只需要和第一行的键值匹配，就可以决定下一个块
的位置（方向）。 因此有效数据是每个块（最后一个块除外）的第一行的数据。还是根据减少无
效数据IO的原则，将每一个块的第一行的数据单独拿出来，和索引数组的地址放到一起。这样就
可以直接在这个数组上进行折半查找了。如下图所示，这个数组就进化成了Sparse Index。

                    Fig. 5

  因为Sparse Index和Dense Index的存储结构是相同的，所以占用的空间也相同。大约需
要10个块来存储10000个Dense Index块的地址和首行键值。通过Sparse索引，仅需要读
取10(Sparse块)+1(Dense块)+1(数据块)=12个块.

- 多层Sparse Index

因为Sparse Index本身是有序的，所以可以为Sparse Index再建sparse Index。通过
这个方法，一层一层的建立 Sparse Indexes,直到最上层的Sparse Index只占用一个块
为止,如下图所示.

                   Fig. 6

  A. 这个最上层的Sparse Index称作整个索引树的根(root).
B. 每次进行定位操作时，都从根开始查找。
C. 每层索引只需要读出一个块。
D. 最底层的Dense Index或数据称作叶子(leaf).
E. 每次查找都必须要搜索到叶子节点，才能定位到数据。
F. 索引的层数称作索引树的高度(height).
G. 索引的IO性能和索引树的高度密切相关。索引树越高，磁盘IO越多。

在我们的例子中的Sparse Index，只有10个块，因此我们只需要再建立一个Sparse Index.
通过两层Sparse Index和一层Dense Index查找时，只需读取1+1+1+1=4个块。

- Dense Index和Sparse Index的区别

A. Dense Index包含所有数据的键值，但是Sparse Index仅包含部分键值。
Sparse Index占用更少的磁盘空间。
B. Dense Index指向的数据可以是无序的，但是Sparse Index的数据必须是有序的。
C. Sparse Index 可以用来做索引的索引，但是Dense Index不可以。
D. 在数据是有序的时候，Sparse Index更有效。因此Dense Index仅用于无序的数据。

- 簇索引(Clustered Index)和辅助索引(Secondary Index)

如果数据本身是基于某个Key来排序的，那么可以直接在数据上建立sparse索引，
而不需要建立一个dense索引层。 如下图所示：

                Fig. 7

  这个索引就是我们常说的“Clustered Index”,而用来排序数据的键叫做主键Primary Key.

A. 一个表只能有一个Clustered Index,因为数据只能根据一个键排序.
B. 用其他的键来建立索引树时，必须要先建立一个dense索引层，在dense索引层上对此键的值
进行排序。这样的索引树称作Secondary Index.
C. 一个表上可以有多个Secondary Index.

- 范围搜索(Range Search)

由于键值是有序的，因此可以进行范围查找。只需要将数据块、Dense Index块分别以双向链表
的方式进行连接， 就可以实现高效的范围查找。如下图所示：

               Fig. 8

  范围查找的过程：

  A. 选择一个合适的边界值，定位该值数据所在的块

  B. 然后选择合适的方向，在数据块（或Dense Index块）链中进行遍历。

  C. 直到数据不满足另一个边界值，结束范围查找。

是不是看着这个索引树很眼熟？换个角度看看这个图吧！

Fig. 9

这分明就是传说中的B+Tree.

- 索引上的操作

  A. 插入键值

  B. 删除键值

  C. 分裂一个节点

  D. 合并两个节点

这些操作在教科书上都有介绍，这里就不介绍了。

先写到这吧，实在写不动了，想明白容易，写明白就难了。下一篇里，打算谈谈标准B+Tree的几个问题，以及在

实现过程中，B+Tree的一些变形。

很多知识来自于下面这两本书。

“Database Systems: The Complete Book (2nd Edition) ”
“Transaction Processing: Concepts and Techniques”

您可能也喜欢：
MySQL索引的索引长度问题	MySQL索引分析和优化（转）	查看mysql索引使用情况	mysql各种HA方案
无觅

在使用MySQL的应用中，如果你的MySQL Server压力逐渐增大，在应用层优化已经到了一定瓶颈时，那么你应该首先考虑MySQL_Replication。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。

如何同步

1. 主库将所有的更新操作，写入二进制日志。
2. 从库运行"IO线程"（Slave IO Thread）读取主库的二进制日志。
3. 从库运行"SQL线程"（Slave SQL Thread）执行IO线程（Slave IO Thread）读取的日志中的SQL,从而保持和主库的一致。

如何分配请求

1. 目前，这部分需要在应用层实现。
2. 执行更新SQL(UPDATE，INSERT，DELETE)时，请求主库。
3. 执行查询SQL(SELECT)时，请求从库。

所以，当你的应用(Application)SELECT请求所占的比率越大，那么Relication就会越有效。

相关教程:

MySQL传输二进制日志原理:http://blog.haohtml.com/archives/12094

您可能也喜欢：
深入Mysql字符集设置	使用MySQL Proxy和MySQL Replication实现读写分离	图解”How MySQL Replication Works”	使用mysql-proxy实现mysql读写分离
无觅

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。示意图：

在主库端一旦有新的日志产生后，立刻会发送一次广播，dump线程在收到广播后，则会读取二进制日志并通过网络向备库传输日志，所以这是一个主库向备库不断推送的过程；

新日志在产生后，只需一次广播和网络就会立刻（<1ms）向发送到备库，如果主备之间网络较好的话（例如RTT<1ms），备库端的日志也就小于2ms了。所以，一般的（依赖于RTT），备库的实时性都非常好。

参考：

1. MySQL Replication Manual

2. 图解"How MySQL Replication Works"

您可能也喜欢：
深入Mysql字符集设置	使用MySQL Proxy和MySQL Replication实现读写分离	修改phpMyAdmin使其能够管理多台远程MySQL 服务器[转载]	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语句的解析，优化器优化以及向存储引擎请求数据等），极大的提高性能。

当然，Query Cache 也有一个致命的缺陷，那就是当某个表的数据有任何任何变化，都会导致所有引用了该表的select语句在Query Cache 中的缓存数据失效。所以，当我们的数据变化非常频繁的情况下，使用Query Cache 可能会得不偿失。

Query Cache的使用需要多个参数配合，其中最为关键的是 query_cache_size 和 query_cache_type ，前者设置用于缓存 ResultSet 的内存大小，后者设置在何场景下使用 Query Cache。在以往的经验来看，如果不是用来缓存基本不变的数据的MySQL数据库，query_cache_size 一般 256MB 是一个比较合适的大小。当然，这可以通过计算Query Cache的命中率（Qcache_hits/(Qcache_hits+Qcache_inserts)*100)）来进行调整。query_cache_type可以设置为0(OFF)，1(ON)或者2(DEMOND)，分别表示完全不使用query cache，除显式要求不使用query cache（使用sql_no_cache）之外的所有的select都使用query cache，只有显示要求才使用query cache（使用sql_cache）。

• binlog_cache_size （global）

Binlog Cache 用于在打开了二进制日志（binlog）记录功能的环境，是 MySQL 用来提高binlog的记录效率而设计的一个用于短时间内临时缓存binlog数据的内存区域。

一般来说，如果我们的数据库中没有什么大事务，写入也不是特别频繁，2MB～4MB是一个合适的选择。但是如果我们的数据库大事务较多，写入量比较大，可与适当调高binlog_cache_size。同时，我们可以通过binlog_cache_use 以及 binlog_cache_disk_use来分析设置的binlog_cache_size是否足够，是否有大量的binlog_cache由于内存大小不够而使用临时文件（binlog_cache_disk_use）来缓存了。

• key_buffer_size （global）

Key Buffer 可能是大家最为熟悉的一个 MySQL 缓存参数了，尤其是在 MySQL 没有更换默认存储引擎的时候，很多朋友可能会发现，默认的 MySQL 配置文件中设置最大的一个内存参数就是这个参数了。key_buffer_size 参数用来设置用于缓存 MyISAM存储引擎中索引文件的内存区域大小。如果我们有足够的内存，这个缓存区域最好是能够存放下我们所有的 MyISAM 引擎表的所有索引，以尽可能提高性能。

此外，当我们在使用MyISAM 存储的时候有一个及其重要的点需要注意，由于 MyISAM 引擎的特性限制了他仅仅只会缓存索引块到内存中，而不会缓存表数据库块。所以，我们的 SQL 一定要尽可能让过滤条件都在索引中，以便让缓存帮助我们提高查询效率。

• bulk_insert_buffer_size （thread）

和key_buffer_size一样，这个参数同样也仅作用于使用 MyISAM存储引擎，用来缓存批量插入数据的时候临时缓存写入数据。当我们使用如下几种数据写入语句的时候，会使用这个内存区域来缓存批量结构的数据以帮助批量写入数据文件：

insert … select …
insert … values (…) ,(…),(…)…
load data infile… into… (非空表)

• innodb_buffer_pool_size（global）

当我们使用InnoDB存储引擎的时候，innodb_buffer_pool_size 参数可能是影响我们性能的最为关键的一个参数了，他用来设置用于缓存 InnoDB 索引及数据块的内存区域大小，类似于 MyISAM 存储引擎的 key_buffer_size 参数，当然，可能更像是 Oracle 的 db_cache_size。简单来说，当我们操作一个 InnoDB 表的时候，返回的所有数据或者去数据过程中用到的任何一个索引块，都会在这个内存区域中走一遭。

和key_buffer_size 对于 MyISAM 引擎一样，innodb_buffer_pool_size 设置了 InnoDB 存储引擎需求最大的一块内存区域的大小，直接关系到 InnoDB存储引擎的性能，所以如果我们有足够的内存，尽可将该参数设置到足够打，将尽可能多的 InnoDB 的索引及数据都放入到该缓存区域中，直至全部。

我们可以通过 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算缓存命中率，并根据命中率来调整 innodb_buffer_pool_size 参数大小进行优化。

• innodb_additional_mem_pool_size（global）

这个参数我们平时调整的可能不是太多，很多人都使用了默认值，可能很多人都不是太熟悉这个参数的作用。innodb_additional_mem_pool_size 设置了InnoDB存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小，所以当我们一个MySQL Instance中的数据库对象非常多的时候，是需要适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率的。

这个参数大小是否足够还是比较容易知道的，因为当过小的时候，MySQL 会记录 Warning 信息到数据库的 error log 中，这时候你就知道该调整这个参数大小了。

• innodb_log_buffer_size （global）

这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer，InnoDB 在写事务日志的时候，为了提高性能，也是先将信息写入 Innofb Log Buffer 中，当满足 innodb_flush_log_trx_commit 参数所设置的相应条件（或者日志缓冲区写满）之后，才会将日志写到文件（或者同步到磁盘）中。可以通过 innodb_log_buffer_size 参数设置其可以使用的最大内存空间。
注：innodb_flush_log_trx_commit 参数对 InnoDB Log 的写入性能有非常关键的影响。该参数可以设置为0，1，2，解释如下：

0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步操作，但是每个事务的commit并不会触发任何log buffer 到log file的刷新或者文件系统到磁盘的刷新操作；
1：在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步；
2：事务提交会触发log buffer 到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操作。

此外，MySQL文档中还提到，这几种设置中的每秒同步一次的机制，可能并不会完全确保非常准确的每秒就一定会发生同步，还取决于进程调度的问题。实际上，InnoDB 能否真正满足此参数所设置值代表的意义正常 Recovery 还是受到了不同 OS 下文件系统以及磁盘本身的限制，可能有些时候在并没有真正完成磁盘同步的情况下也会告诉 mysqld 已经完成了磁盘同步。

• innodb_max_dirty_pages_pct （global）

这个参数和上面的各个参数不同，他不是用来设置用于缓存某种数据的内存大小的一个参数，而是用来控制在 InnoDB Buffer Pool 中可以不用写入数据文件中的Dirty Page 的比例（已经被修但还没有从内存中写入到数据文件的脏数据）。这个比例值越大，从内存到磁盘的写入操作就会相对减少，所以能够一定程度下减少写入操作的磁盘IO。

但是，如果这个比例值过大，当数据库 Crash 之后重启的时间可能就会很长，因为会有大量的事务数据需要从日志文件恢复出来写入数据文件中。同时，过大的比例值同时可能也会造成在达到比例设定上限后的 flush 操作“过猛”而导致性能波动很大。

您可能也喜欢：
mysql limit查询优化	MySQL性能优化的最佳20+条经验	MySQL 数据库优化（11）The Query Optimization Process	mysql查询语句优化命令mysql explain
无觅

innodb_data_file_path=datafile_spec1[;datafile_spec2]...

[mysqld]
innodb_data_file_path = /db/ibdata1:2000M;/dr2/db/ibdata2:2000M:autoextend

mysql> show variables like 'innodb_file_per_table'\G;
*************************** 1. row ***************************
Variable_name: innodb_file_per_table
Value: ON
1 row in set (0.00 sec)

mysql> system ls -lh /usr/local/mysql/data/member/*
-rw-r-----  1 mysql mysql 8.7K 2009-02-24  /usr/local/mysql/data/member/ Profile.frm
-rw-r-----  1 mysql mysql 1.7G  9月 25 11:13 /usr/local/mysql/data/member/ Profile.ibd
-rw-rw----  1 mysql mysql 8.7K  9月 27 13:38 /usr/local/mysql/data/member/t1.frm
-rw-rw----  1 mysql mysql  17M  9月 27 13:40 /usr/local/mysql/data/member/t1.ibd
-rw-rw----  1 mysql mysql 8.7K  9月 27 15:42 /usr/local/mysql/data/member/t2.frm
-rw-rw----  1 mysql mysql  17M  9月 27 15:54 /usr/local/mysql/data/member/t2.ibd

mysql> show variables like 'innodb%log%'\G;
*************************** 1. row ***************************
Variable_name: innodb_flush_log_at_trx_commit
Value: 1
*************************** 2. row ***************************
Variable_name: innodb_locks_unsafe_for_binlog
Value: OFF
*************************** 3. row ***************************
Variable_name: innodb_log_buffer_size
Value: 8388608
*************************** 4. row ***************************
Variable_name: innodb_log_file_size
Value: 5242880
*************************** 5. row ***************************
Variable_name: innodb_log_files_in_group
Value: 2
*************************** 6. row ***************************
Variable_name: innodb_log_group_home_dir
Value: ./
*************************** 7. row ***************************
Variable_name: innodb_mirrored_log_groups
Value: 1
7 rows in set (0.00 sec)

090924 11:39:44  InnoDB: ERROR: the age of the last checkpoint is 9433712,

InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.
090924 11:40:00  InnoDB: ERROR: the age of the last checkpoint is 9433823,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.
090924 11:40:16  InnoDB: ERROR: the age of the last checkpoint is 9433645,
InnoDB: which exceeds the log group capacity 9433498.
InnoDB: If you are using big BLOB or TEXT rows, you must set the
InnoDB: combined size of log files at least 10 times bigger than the
InnoDB: largest such row.

您可能也喜欢：
mysql中使用InnoDB还是MyISAM ?	Mysql InnoDB和MyISAM的区别	解决Default storage engine (InnoDB) is not available导致mysql无法启动的	使用MySQL Proxy和MySQL Replication实现读写分离
无觅

并不是所有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 "%date%" >> %LOG_FILE%
echo "" >> %LOG_FILE%

部署完脚本后，剩下的就是在系统中添加“计划任务”项目了。

您可能也喜欢：
使用mysql-proxy实现mysql读写分离	修改phpMyAdmin使其能够管理多台远程MySQL 服务器[转载]	MySQL数据库服务器在Flickr、Fotolog、 Wkipedia、Facebook等国际知名网站中的使用数量	MySQL 备份(推荐方法)
无觅

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/

您可能也喜欢：
MySQL传输二进制日志原理	mysql各种HA方案	MySQL远程访问时非常慢的解决办法	MySQL Timeout解析
无觅

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即可，当然以后根据需要增加用户和数据库。

#mysql> show databases;
#mysql> drop database test; //删除数据库test
#use mysql;
#delete from db; //删除存放数据库的表信息，因为还没有数据库信息。
#mysql> delete from user where not (user=’root’) ; // 删除初始非root的用户
#mysql> delete from user where user=’root’ and password=”; //删除空密码的root，尽量重复操作
Query OK, 2 rows affected (0.00 sec)
#mysql> flush privileges; //强制刷新内存授权表。

3.改变默认mysql管理员帐号
4.关于密码的管理
密码是数据库安全管理的一个很重要因素，不要将纯文本密码保存到数据库中。如果你的计算机有安全危险，入侵者可以获得所有的密码并使用它们。相反，应使用MD5()、SHA1()或单向哈希函数。也不要从词典中选择密码，有专门的程序可以破解它们，请选用至少八位，由字母、数字和符号组成的强密码。在存取密码时，使用mysql的内置函数password（）的sql语句，对密码进行加密后存储。例如以下方式在users表中加入新用户。

#mysql> insert into users values (1,password(1234),’test’);

5.使用独立用户运行msyql
绝对不要作为使用root用户运行MySQL服务器。这样做非常危险，因为任何具有FILE权限的用户能够用root创建文件(例如，~root/.bashrc)。mysqld拒绝使用root运行，除非使用–user=root选项明显指定。应该用普通非特权用户运行mysqld。正如前面的安装过程一样，为数据库建立独立的linux中的mysql账户，该账户用来只用于管理和运行MySQL。

要想用其它Unix用户启动mysqld，，增加user选项指定/etc/my.cnf选项文件或服务器数据目录的my.cnf选项文件中的[mysqld]组的用户名。

#vi /etc/my.cnf
[mysqld]
user=mysql

该命令使服务器用指定的用户来启动，无论你手动启动或通过mysqld_safe或mysql.server启动，都能确保使用mysql的身份。也可以在启动数据库是，加上user参数。

# /usr/local/mysql/bin/mysqld_safe –user=mysql &

作为其它linux用户而不用root运行mysqld，你不需要更改user表中的root用户名，因为MySQL账户的用户名与linux账户的用户名无关。确保mysqld运行时，只使用对数据库目录具有读或写权限的linux用户来运行。

6.禁止远程连接数据库

在命令行netstat -ant下看到，默认的3306端口是打开的，此时打开了mysqld的网络监听，允许用户远程通过帐号密码连接数本地据库，默认情况是允许远程连接数据的。为了禁止该功能，启动skip-networking，不监听sql的任何TCP/IP的连接，切断远程访问的权利，保证安全性。假如需要远程管理数据库，可通过安装PhpMyadmin来实现。假如确实需要远程连接数据库，至少修改默认的监听端口，同时添加防火墙规则，只允许可信任的网络的mysql监听端口的数据通过。

# vi /etc/my.cf
将#skip-networking注释去掉。
# /usr/local/mysql/bin/mysqladmin -u root -p shutdown //停止数据库
#/usr/local/mysql/bin/mysqld_safe –user=mysql & //后台用mysql用户启动mysql

7.限制连接用户的数量
数据库的某用户多次远程连接，会导致性能的下降和影响其他用户的操作，有必要对其进行限制。可以通过限制单个账户允许的连接数量来实现，设置my.cnf文件的mysqld中的max_user_connections变量来完成。GRANT语句也可以支持 资源控制选项来限制服务器对一个账户允许的使用范围。

#vi /etc/my.cnf
[mysqld]
max_user_connections 2

8.用户目录权限限制
默认的mysql是安装在/usr/local/mysql，而对应的数据库文件在/usr/local/mysql/var目录下，因此，必须保证该目录不能让未经授权的用户访问后把数据库打包拷贝走了，所以要限制对该目录的访问。确保mysqld运行时，只使用对数据库目录具有读或写权限的linux用户来运行。

# chown -R root /usr/local/mysql/ //mysql主目录给root
# chown -R mysql.mysql /usr/local/mysql/var //确保数据库目录权限所属mysql用户

9.命令历史记录保护
数据库相关的shell操作命令都会分别记录在.bash_history，如果这些文件不慎被读取，会导致数据库密码和数据库结构等信息泄露，而登陆数据库后的操作将记录在.mysql_history文件中，如果使用update表信息来修改数据库用户密码的话，也会被读取密码，因此需要删除这两个文件，同时在进行登陆或备份数据库等与密码相关操作时，应该使用-p参数加入提示输入密码后，隐式输入密码，建议将以上文件置空。

# rm .bash_history .mysql_history //删除历史记录
# ln -s /dev/null .bash_history //将shell记录文件置空
# ln -s /dev/null .mysql_history //将mysql记录文件置空

10.禁止MySQL对本地文件存取
在mysql中，提供对本地文件的读取，使用的是load data local infile命令，默认在5.0版本中，该选项是默认打开的，该操作令会利用MySQL把本地文件读到数据库中，然后用户就可以非法获取敏感信息了，假如你不需要读取本地文件，请务必关闭。应该禁止MySQL中用“LOAD DATA LOCAL INFILE”命令。网络上流传的一些攻击方法中就有用它LOAD DATA LOCAL INFILE的，同时它也是很多新发现的SQL Injection攻击利用的手段！黑客还能通过使用LOAD DATALOCAL INFILE装载“/etc/passwd”进一个数据库表，然后能用SELECT显示它，这个操作对服务器的安全来说，是致命的。可以在my.cnf中添加local-infile=0，或者加参数local-infile=0启动mysql。

#/usr/local/mysql/bin/mysqld_safe –user=mysql –local-infile=0 &
#mysql> load data local infile ’sqlfile.txt’ into table users fields terminated by ‘,’;
#ERROR 1148 (42000): The used command is not allowed with this MySQL version

–local-infile=0选项启动mysqld从服务器端禁用所有LOAD DATA LOCAL命令，假如需要获取本地文件，需要打开，但是建议关闭。

11.MySQL服务器权限控制
MySQL权限系统的主要功能是证实连接到一台给定主机的用户，并且赋予该用户在数据库上的SELECT、INSERT、UPDATE和DELETE等权限（详见user超级用户表）。它的附加的功能包括有匿名的用户并对于MySQL特定的功能例如LOAD DATA INFILE进行授权及管理操作的能力。

管理员可以对user，db，host等表进行配置，来控制用户的访问权限，而user表权限是超级用户权限。只把user表的权限授予超级用户如服务器或数据库主管是明智的。对其他用户，你应该把在user表中的权限设成’N'并且仅在特定数据库的基础上授权。你可以为特定的数据库、表或列授权，FILE权限给予你用LOAD DATA INFILE和SELECT … INTO OUTFILE语句读和写服务器上的文件，任何被授予FILE权限的用户都能读或写MySQL服务器能读或写的任何文件。(说明用户可以读任何数据库目录下的文件，因为服务器可以访问这些文件）。 FILE权限允许用户在MySQL服务器具有写权限的目录下创建新文件，但不能覆盖已有文件在user表的File_priv设置Y或N。，所以当你不需要对服务器文件读取时，请关闭该权限。

#mysql> load data infile ’sqlfile.txt’ into table loadfile.users fields terminated by ‘,’;
Query OK, 4 rows affected (0.00 sec) //读取本地信息sqlfile.txt’
Records: 4 Deleted: 0 Skipped: 0 Warnings: 0
#mysql> update user set File_priv=’N’ where user=’root’; //禁止读取权限
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> flush privileges; //刷新授权表
Query OK, 0 rows affected (0.00 sec)
#mysql> load data infile ’sqlfile.txt’ into table users fields terminated by ‘,’; //重登陆读取文件
#ERROR 1045 (28000): Access denied for user ‘root’@'localhost’ (using password: YES) //失败
# mysql> select * from loadfile.users into outfile ‘test.txt’ fields terminated by ‘,’;
ERROR 1045 (28000): Access denied for user ‘root’@'localhost’ (using password: YES)

为了安全起见，随时使用SHOW GRANTS语句检查查看谁已经访问了什么。然后使用REVOKE语句删除不再需要的权限。

12.使用chroot方式来控制MySQL的运行目录
Chroot是linux中的一种系统高级保护手段，它的建立会将其与主系统几乎完全隔离，也就是说，一旦遭到什么问题，也不会危及到正在运行的主系统。这是一个非常有效的办法，特别是在配置网络服务程序的时候。

13.关闭对无关的Web程序访问的支持

如果不打算让Web访问使用MySQL数据库，没有提供诸如PHP这样的Web语言的时候，重新设置或编译你的PHP，取消它们对MySQL的默认支持。假如服务器中使用php等web程序，试试用Web形式非法的请求，如果得到任何形式的MySQL错误，立即分析原因，及时修改Web程序，堵住漏洞，防止MySQL暴露在web面前。
对于Web的安全检查，在MySQL官方文档中这么建议，对于web应用，至少检查以下清单：

• 试试用Web形式输入单引号和双引号(‘’’和‘”’)。如果得到任何形式的MySQL错误，立即分析原因。
• 试试修改动态URL，可以在其中添加%22(‘”’)、%23(‘#’)和%27(‘’’)。
• 试试在动态URL中修改数据类型，使用前面示例中的字符，包括数字和字符类型。你的应用程序应足够安全，可以防范此类修改和类似攻击。
• 试试输入字符、空格和特殊符号，不要输入数值字段的数字。你的应用程序应在将它们传递到MySQL之前将它们删除或生成错误。将未经过检查的值传递给MySQL是很危险的！
• 将数据传给MySQL之前先检查其大小。
• 用管理账户之外的用户名将应用程序连接到数据库。不要给应用程序任何不需要的访问权限。

14.数据库备份策略
使用 mysqldump进行备份非常简单，如果要备份数据库” nagios_db_backup ”，使用命令，同时使用管道gzip命令对备份文件进行压缩，建议使用异地备份的形式，可以采用Rsync等方式，将备份服务器的目录挂载到数据库服务器，将数据库文件备份打包在，通过crontab定时备份数据：

#!/bin/sh
time=`date +”(“%F”)”%R`
$/usr/local/mysql/bin/mysqldump -u nagios -pnagios nagios | gzip >/home/sszheng/nfs58/nagiosbackup/nagios_backup.$time.gz
# crontab -l
# m h dom mon dow command
00 00 * * * /home/sszheng/shnagios/backup.sh

恢复数据使用命令：

gzip -d nagios_backup.\(2008-01-24\)00\:00.gz
nagios_backup.(2008-01-24)00:00
#mysql –u root -p nagios < /home/sszheng/nfs58/nagiosbackup/nagios_backup.\(2008-01-24\)12\:00

15. Mysqld安全相关启动选项
–local-infile[={0|1}]
如果用–local-infile=0启动服务器，则客户端不能使用LOCAL in LOAD DATA语句。
–old-passwords
强制服务器为新密码生成短(pre-4.1)密码哈希。当服务器必须支持旧版本客户端程序时，为了保证兼容性这很有用。
(OBSOLETE) –safe-show-database
在以前版本的MySQL中，该选项使SHOW DATABASES语句只显示用户具有部分权限的数据库名。在MySQL 5.1中，该选项不再作为现在的 默认行为使用，有一个SHOW DATABASES权限可以用来控制每个账户对数据库名的访问。
–safe-user-create
如果启用，用户不能用GRANT语句创建新用户，除非用户有mysql.user表的INSERT权限。如果你想让用户具有授权权限来创建新用户，你应给用户授予下面的权限：
mysql> GRANT INSERT(user) ON mysql.user TO ‘user_name’@'host_name’;
这样确保用户不能直接更改权限列，必须使用GRANT语句给其它用户授予该权限。
–secure-auth
不允许鉴定有旧(pre-4.1)密码的账户。

16.information_schema 安全

这个问题一直没有解决吗，但是很重要，黑客可以通过它列出库内的表名和字段账号密码，可以参考官方有如下俩个提出

http://bugs.mysql.com/bug.php?id=38837

http://bugs.mysql.com/bug.php?id=27629

Phpmyadmin里隐藏方法

$cfg['servers'][$i]['hide_db'] = ‘information_schema’;

PHP IDS
memechae 代理

knock

1.php?id=1
1.php/?id=1

您可能也喜欢：
深入Mysql字符集设置	使用MySQL Proxy和MySQL Replication实现读写分离	MySQL数据库服务器在Flickr、Fotolog、 Wkipedia、Facebook等国际知名网站中的使用数量	图解"How MySQL Replication Works"
无觅

从mysqldump到Xtrabackup

我们使用mysqldump来进行每日的数据库备份,mysqldump对数据进行逻辑备份,就像应用访问数据库那样,mysqldump以SQL语句的方式从数据库中读取一张张表,将表结构和数据转保存到文本文件.mysqldump最大的问题是速度太慢(对于我们的一些大的数据库,通常要花24小时,甚至更久),并且以SQL语句的方式读取数据可能造成磁盘的随机读,这就会造成主机的load增大,影响性能.对于时间太长,我们可以跑多个实例来并发的做备份,这能缩短备份的时间,但是会造成更多的load,更影响主机的性能.

另外一个可行的备份方式是进行物理备份(我们称之为二进制备份,binary backup),通过操作系统层面,读取数据库磁盘文件,而非通过SQL语句.这样的话在备份的过程中,数据不能像SQL读取的时候保持事务上一致的.只有当备份的数据文件在数据库里复原了,他们才又一致了,这类似于数据库down掉之重启一样.

我们通过修改增强Xtrabackup来满足我们额外的需求:

1.支持快速的表级还原

2.增强全量和增量备份

3.支持混合增量备份

Xtrabackup支持增量备份,也就是备份自上次全量备份后改变的数据.这样我们就能够减少备份的空间(比如每天一次增量备份,每周一次全量备份).Xtrabackup也支持多级增量备份,不过我们不使用,避免复杂.

1.表级还原

我们写了一个PHP脚本,来从二进制备份文件中读取并还原指定的表.当前,这个脚本还不能自己从备份文件中读取信息创建表结构,因此必须事先准备好一个对应的空的表.我们对Xtrabackup也做了相应的修改来支持这个工具.这个修改就是支持Xtrabackup导入导出单表.单表的还原比全量还原快得多,因为只需要从文件中读取相应的表的信息.

2.调整全量和增量复制

fb是Xtrabackup早期的增量备份功能的用户,起初对于一些有大量表的数据库，Xtrabackup的增量备份不起作用.后来我们和percona一起解决了这些问题.

Xtrabackup只有本地增量备份功能,也就是说增量备份的文件必须要和MySQL在同台主机上.我们修改使之支持远程增量备份,也就是通过类似管道的方式将备份的数据同时发送到远程主机,.如果先在本地做增量备份,然后通过网络传到远程主机,对我们来说是不可取的,因为会大大增加本地的写操作.

Xtrabackup以1MB为1个chunk来读取数据库文件,我们发现使用8MB时,能够使增量备份的速度快一倍,使全量备份快40%.

3.让增量备份成为真正的增量

Xtrabackup的增量备份读取数据库的每个page,来判断哪些page改变了.我们创建了一个page追踪器,通过读取事务日志,并且通过每个表的bitmap,来追踪修改过的page,.这样我们就能很好的追踪哪些page改变了哪些没变,我们就可以只读取那些改变过的page.我们称这位真正的增量备份.

不过讽刺的是,我们发现这种真正的增量备份比普通的增量备份反而来的慢..这是因为普通的增量备份用8MB的chunk来读取文件,而真正的增量备份读取文件的大小是不定的,从16KB(INNODB中一个page的大小)到8MB,这取决于有多少连续的page是被修改过的.因此在我们的很多场景下(自上次全量备份后大概10%-30%的page修改了),真正的增量备份比普通的增量备份花了更多的IO调用.

因为我们进行了改进,有了一种混合增量的备份，通过避免读取未修改的page来减少IO次数,在我们的场景下,这种混合增量备份减少了20%-30%的IO,IO的大小从16KB到8MB不等.

下表描述了使用上述改进的方法来处理大概750GB数据时产生的不同结果.由于mysqldump速度的原因,mysqldump只在少数几个数据库上跑,我们使用gzip来对mysqldump的结果进行压缩,很慢,但是压缩率很高.

QPress用来压缩二进制备份,它比gzip快多了,但是压缩效率更低.由于我们经常作增量备份,较少作全量备份,整个二进制备份所需要的空间和mysqldump所需要的空间还是差不多的.

原文意译:http://www.facebook.com/note.php?note_id=10150098033318920

您可能也喜欢：
MySQL 备份(推荐方法)	图解"How MySQL Replication Works"	MySQL数据库备份及恢复命令及常用应用举例	详细讲解MySQL数据库双机热备的配置方法
无觅