MyISAM的索引是直接指向存储的数据行的物理位置，而InnoDB则是指向primary key，即是对于InnoDB而言，Key ‘im_a_index’ (id)这样的索引，其索引的数据里面指向的不是数据行的物理位置，而是数据行的primary key，因此使用索引查询其实会产生两次查询，首先是在索引里面获取查询数据的primary key，然后再通过primary key查询到真正的数据。因此，也出现了一个概念叫”Covering Index”，这个不是什么新鲜的概念，” An index that contains (or covers) all the data needed to satisfy a query is called a covering index. “，正是由于InnoDB要二次查询数据行的原因，covering index就让所有使用这个索引查询的数据都放在索引里面，对于”select * from table_name where …”这些要获取所有列的数据，那么就肯定会用不上这个covering index的好处了。当然，covering index也并不是鼓励所有的查询都新建一个index来体验covering index的好处，太多的index不但会使索引占用的容量增大难以维护，而且也会使update、delete、insert的成本提高很多，具体还是要看项目数据的需求而定，何况，一个数据访问量不大的小项目，就觉得没有什么必要了。对于B-Tree索引，应用索引除了要遵循leftmost prefix之外，在第一个range condition后面的列都不会应用到索引的，其实也就是索引会匹配这样的(equality, equality, range)这样的条件，但是在(equality, equality, range, equality, range..)这样的条件下，在第一个range后面的都不会享受到index的待遇。

” Clustered indexes aren’t a separate type of index. Rather, they’re an approach to data storage. The exact details vary between implementations, but InnoDB’s clustered indexes actually store a B-Tree index and the rows together in the same structure. “由于clustered index只是一种数据存储的方式，因此对于每个表只能拥有一个clustered index。目前支持这种建立索引的存储方式的只有solidDB和InnoDB支持。如果在InnoDB表中没有定义一个primary key，InnoDB会自动使用一个unique nonnullable index来替代primary key，如果没有这样的index，InnoDB将会隐式定义一个primary key，并此primary key上建立clustered index。” InnoDB stores each record immediately after the one before, because the primary key values are sequential. When the page reaches its maximum fill factor (InnoDB’s initial fill factor is only 15/16 full, to leave room for modifications later), the next record goes into a new page. “。

” Ordering the results by the index works only when the index’s order is exactly the same as the ORDER BY clause and all columns are sorted in the same direction(ascending or descending). “使用索引来排序与使用索引查询的约束差不多，只要WHERE和ORDER BY遵循leftmost prefix就基本可以了，ORDER BY子句的排序列不能是不同方向的排序。

MyISAM可以使用Prefix-Compressed的方式来建立Packed Indexes。” For example, if the first value is ‘perform’ and the second is ‘performance’, the second value will be stored analogously to ’7,ance’. “使用这种方式来建立索引，可以节约不少空间，” Packed indexes can be about one-tenth the size on disk. “。同时，这样可以使顺序扫描性能表现很好，但是使用反序扫描的话则会成为一个问题。实际上，这种索引的代价就是 CPU&Memory resources vs. disk resources。

对于这样的select语句” SELECT actor_id FROM table_name WHERE actor_id < 5 AND actor_id <> 1 FOR UPDATE “，（actor_id是索引）虽然返回的结果不包括actor_id=1的情况，但实际上在事务过程中InnoDB会把actor_id=1的行加锁。这说明了MySQL Server是在存储引擎返回了行之后再应用WHERE filter。关于InnoDB，indexes和locking还有一个鲜为人知的细节是，” InnoDB can place shared(read) locks on secondary indexes, but exclusive(write) locks require access to the primary key. That eliminates the possibility of using a covering index and can make SELECT FOR UPDATE much slower than LOCK IN SHARE MODE or a nonlocking query. “

ibbackup备份的基本命令：

#ibbackup 传入两个配置文件的路径参数
ibbackup /path/to/my.cnf /path/to/my2.cnf
#典型的：
ibbackup /etc/my.cnf /home/mysql/backup-my.cnf

ibbackup会根据第一个参数中的my.cnf文件，获取需要备份的InnoDB的数据文件ibdata和日志文件ib_logfile的位置，并将其备份到第二个参数my2.cnf所指定的位置，ibbackup将读取第一个参数my.cnf中的如下内容：

datadir=...
innodb_data_home_dir=...
innodb_data_file_path=...
innodb_log_group_home_dir=...
innodb_log_files_in_group=...
innodb_log_file_size=...
#这里需要注意的是,很多的配置文件 my.cnf 中是没有 innodb_log_group_home_dir 和innodb_data_home_dir,这样ibbackup 会执行失败。

在第二个配置文件my2.cnf中的datadir、innodb_data_home_dir和innodb_log_group_home_dir是填写备份的目录，而且这些目录是要填写绝对路径的，因为ibbackup不识别这些文件中填写的相对路径。两个配置文件my.cnf和my2.cnf中关于数据文件的数量和大小设置必须相同，包括autoextend参数也要保持一致，而日志文件则可以不一样。

my.cnf

datadir = /var/lib/mysql
innodb_data_home_dir = /var/lib/mysql
innodb_data_file_path = ibdata1:1G:autoextend
innodb_log_group_home_dir = /var/lib/mysql
innodb_log_files_in_group = 2
innodb_log_file_size=256M

backup-my.cnf

datadir = /home/mysql/backup
innodb_data_home_dir = /home/mysql/backup
innodb_data_file_path = ibdata1:1G:autoextend
innodb_log_group_home_dir = /home/mysql/backup
innodb_log_files_in_group = 2
innodb_log_file_size=256M
#innodb_log_arch_dir 是mysql5.0支持的参数，在mysql5.1中已经被innodb_log_group_home_dir替代

ibbackup备份的只是InnoDB的数据文件和日志文件，而并没有备份.frm文件。因此.frm文件还需手动copy或者是使用mysqldump命令进行备份。

准备好之后，就运行备份命令：

ibbackup --compress /etc/my.cnf /home/mysql/backup-my.cnf

–compress是压缩备份，恢复的时候也相应添上–uncompress，压缩备份的数据文件是有.ibz后缀的。成功备份后在备份的目录下就会有ibbackup_logfile和ibdata*.ibz等文件。

２.恢复

恢复主要有三个步骤，恢复日志、启动备份的mysql、故障数据恢复。

1. 进行日志重做
   ibbackup在备份期间用日志文件ibbackup_logfile记录了备份期间数据的变化，在恢复的时候是使用此日志对备份的数据进行日志重做。参考手册中说“By applying that file to the backed up data files we can roll forward them so that every page in the data files corresponds to the same log sequence number of the InnoDB log.”，但具体日志重做的细节还没有找到相关的资料。日志重做使用的命令如下：

   #--uncompress是因为在备份时使用了--compress参数
   ibbackup --apply-log --uncompress /home/mysql/backup-my.cnf

   在运行了这个命令之后，ibbackup便开始进行日志恢复，日志重做后会在备份的目录生成ib_logfile*和ibdata*等文件。然后在输出的信息中，有一处比较重要是：

   #file name后面的路径为mysql的BINLOG目录，其他的输出信息忽略
   ibbackup: Last MySQL binlog file position 0 969, file name /var/lib/mysql/.../logs/mysql-bin.000001

   这个是指示了备份时的binlog位置，便于在第三步进行binlog数据恢复时用到。可以看到，在mysql-bin.00001的0-969为备份前binlog的位置。

2. 恢复后重启数据库服务
   重启数据库服务器，是指使用backup-my.cnf的配置来启动数据库服务，要注意的是，因此备份的时候只是备份的InnoDB的数据文件和日志文件，如果要重新在另一个目录下启动数据库服务的话，需要将所有在原来mysql的数据目录下的.frm文件目录和mysql目录等文件拷贝到新的目录下。

   mysqld_safe --defaults-file=/home/mysql/backup-my.cnf &

3. 根据BINLOG恢复故障数据
   由于在备份后，数据库可能会存在更改，因此要将那些备份后的数据库更改应用到恢复的状态，这个时候就要根据binlog的记录来恢复。在第一步日志重做的时候，记录下备份前的binlog位置为969，因此，我们在恢复binlog时就是指定–start-position为969，从这个位置开始恢复，同时，如果还有其他的mysql-bin.00000*，也要一起恢复。

   mysqlbinlog --start-position=969 mysql-bin.00001 | mysql -u root -p***

1. DDL(Data Definition Languages)语句：数据定义语言，这些语句定义了不同的数据段、数据库、表、列、索引等数据库对象。常用的语句关键字主要包括create、drop、alter等。
2. DML(Data Manipulation Languages)语句：数据操纵语句，用于添加、删除、更新和查询数据库记录，并检查数据库完整性。常用的语句关键字主要包括insert、delete、update和select等。
3. DCL(Data Control Language)语句：数据控制语句，用于控制不同数据段直接的许可和访问级别的语句。这些语句定义了数据库、表、字段、用户的访问权限和安全级别。主要的语句关键字包括grant、revoke等。
4. change和modify都可以修改表的定义，不同的是change后面需要写两次列名，不方便。但是change的优点是可以修改列名称，modify则不能。

二、    MySQL支持的数据类型

1. MySQL支持的数值类别有TINYINT, SMALLINT, MEDIUMINT, INT/INTEGER, BIGINT, FLOAT, DOUBLE, DEC(M,D)/DECIMAL(M,D), BIT(M)
2. 在5个整数类型中，如果超出类型范围的操作，会发生“Out of range”的错误提示。
3. 对于整型数据，MySQL还支持在类型名称后面的小括号内指定显示宽度，例如int(5)表示当数值小于5位的时候在数字前面填满宽度，如果不显示指定宽度则默认为int(11)。一般配合zerofill使用，zerofill就是用“0”填充的意思，也就是在数字位数不够的空间用字符“0”填满。
4. 一个表中最多只能有一个AUTO_INCREMENT列。对于任何想要使用AUTO_INCREMENT的列，应该定义为NOT NULL，并定义为PRIMARY KEY或定义为UNIQUE键。
5. 浮点数(Float/Double)和定点数(Decimal)都可以用类型名称后加“(M,D)”的方式来进行表示，“(M,D)”表示该值一花显示M位数字(整数位+小数位)，其中D位位于小数点后面，M和D又称为精度和标度。
6. 浮点数如果不写精度和，则会按照实际精度值显示，如果有精度和标度，则会自动将四舍五入的结果插入，系统不会报错；定点数如果不写精度和标度，则按照默认值DECIMAL(10,0)来进行操作，并且如果数据超越了精度和标度值，系统则会报错。
7. BIT(M)可以用来存放多位二进制数，M范围从1~64，如果不写则默认为1位。对于位字段，直接使用SELECT命令将不会看到结果，可以用bin()(显示为二进制格式)或者hex()(显示为十六进制格式)函数进行读取。
8. 数据插入BIT类别字段时，首先转换为二进制，如果位数允许，将成功插入；如果位数小于实际定义的数，则插入失败。如果长度过长则直接所有位填充1(自己测试的)。
9. MySQL中的日期和时间类型有DATE, DATETIME, TIMESTAMP, TIME, YEAR。每种日期时间类型都有一个有效值范围，如果超出这个范围，在默认的SQLMode下，系统会进行错误提示，并将以零值来进行存储。
10. MySQL只给表中的第一个TIMESTAMP字段设置默认值为系统日期，如果有第二个TIMESTAMP类型，则默认值设置为0值，因为MySQL规定TIMESTAMP类型字段只能有一列的默认值为CURRENT_TIMESTAMP。
11. TIMESTAMP还有一个重要特点，会先转换为本地时区后存放；而从数据库里面取出时，也同样需要将日期转换为本地时区后显示。
12. TIMESTAMP的取值范围为19700101080001到2038年的某一天。插入的数值超出下限和上限都会出现警告，并插入0值。
13. DATETIME的格式允许不严格语法：任何标点符都可以用做日期部分或时间部分之间的间隔符。
14. MySQL中支持字符类型有，CHAR(M), VARCHAR(M), TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB, TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT, VARBINARY(M), BINARY(M)。
15. CHAR列的长度固定为创建表时声明的长度，长度可以从0~255的任何值；而VARCHAR列中的值为可变长字符串，长度可以指定为0    ~255(5.0.3以前)或65535(5.0.3之后)之间的值。在检索的时候，CHAR列删除尾部的空格，而VARCHAR则保留这些空格。
16. BINARY和VARBINARY类似于CHAR和VARCHAR，不同的是它们包含二进制字符串而不包含非二进制字符串。当保存BINARY值，在值的最后通过填充“0X00”(零字节)以达到指定的字段长度。

三、   常用函数

1. 字符串函数：
   • CONCAT(S1,S2,…,Sn)：把传入的参数连接成为一个字符串
   • INSERT(str, x, y, instr)：把字符串str从第x位置开始，y个字符长的子串替换为字符串instr
   • LOWER(str)和UPPER(STR)：把字符串的大小写转换
   • LEFT(str, x)和RIGHT(str, x)：返回字符串最左边的x个字符和最右边的x个字符。如果第二个参数为NULL，那么将不返回任何字符串
   • LPAD(str, x, pad)和RPAD(str, n, pad)：用字符串pad对str最左边和最右边进行填充，直到长度为n个字符长度
   • LTRIM(str)和RTRIM(str)：去年字符串str左侧和右侧空格
   • REPEAT(str, x)：返回str重复x次的結果
   • REPLACE(str, a, b)：用字符串b替换字符串str中所有出现的字符串a
   • STRCMP(s1, s2)：比较字符串s1和s2的ASCII码值的大小
   • TRIM(str)：去掉目标字符吕的开头和结尾的空格
   • SUBSTRING(str, x, y)：返回从字符串str中的第x位置起y个字符长度的字串
2. 数值函数：
   • ABS(x)：返回x的绝对值
   • CEIL(x)：返回大于x的最小整数
   • FLOOR(x)：返回小于x的最大整数
   • MOD(x)：返回x/y的模
   • RAND()：返回0～1内的随机值
   • ROUND(x, y)：返回参数x的四舍五入的有y位小数的值
   • TRUNCATE(x, y)：返回数字x截断为y位小数的結果
3. 日期和时间函数：
   • CURDATE()：返回当前日期，只包含年月日
   • CURTIME()：返回当前时间，只包含时分秒
   • NOW()：返回当前的日期和时间，年月日时分秒都包含
   • UNIX_TIMESTAMP(date)：返回日期date的UNIX时间戳
   • FROM_UNIXTIME(unixtime)：返回UNIXTIME时间戳的日期值，和UNIX_TIMESTAMP(date)互为逆操作
   • WEEK(DATE)和YEAR(DATE)：前者返回所给的日期是一年中的第几周，后者返回所给的日期是哪一年
   • HOUR(time)和MINUTE(time)：前者返回所给时间的小时，后者返回所给时间的分钟
   • MONTHNAME(date)：返回date的英文月份名称
   • DATE_FORMAT(date, fmt)：按字符串fmt格式化日期date值
   • DATE_ADD(date, INTERVAL expr type)：返回与所给日期date相差INTERVAL时间段的日期
   • DATEDIFF(date1, date2)：用来计算两个日期之间相关的天数
4. 其他函数
   • DATABASE()：返回当前数据库名
   • VERSION()：返回当前数据库版本
   • USER()：返回当前登录用户名
   • INET_ATON(IP)：返回IP地址的网络字节序表示
   • INET_NTOA(num)：返回网络字节序代表的IP地址
   • PASSWORD(str)：返回字符串str的加密版本，一个41位长的字符串
   • MD5(str)：返回字符串str的MD5值，常用来对应中的数据进行加密

四、   存储引擎

1. MySQL 5.0支持的存储引擎包括 MyISAM、InnoDB、BDB、MEMORY、MERGE、EXAMPLE、NDB Cluster、ARCHIVE、CSV、BLACKHOLE、FEDERATED等，其中InnoDB和BDB提供事务安全表。
2. 如果需要修改默认的存储引擎，则可以在参数文件中设置default-table-type。查看当前的默认存储引擎，可用命令”show variables like ‘table_type’”。
3. 查询当前数据库支持的存储引擎有两种方法。第一种为，”show engines”，第二种为，”show variables like ‘have%’”。
4. MyISAM
   • MySQL的默认存储引擎。MyISAM不支持事务、也不支持外键，其优势是访问的速度快，对事务完整性没有要求或者以SELECT、INSERT为主的应用基本上都可以使用这个引擎来创建表。
   • 每个MyISAM在磁盘上存储成3个文件，其文件名都和表名相同，但扩展名分别是：.frm(存储表定义)、MYD(MYData，存储数据)、MYI(MYIndex，存储索引)。
   • MyISAM的表还支持3种不同的存储格式，分别是静态(固定长度)表、动态表和压缩表。
5. InnoDB
   • InnoDB表的自动增长列可以手工插入，但是插入的值如果是空或者0，则实际插入的将是自动增长后的值。
   • 可以通过”ALTER TABLE *** AUTO_INCREMENT=n;”語句强制设置自动增长列的初识值，默认从1开始，但是该强制的默认值是保留在内存中的，如果该值在使用之前数据库重新启动，那么这个强制的默认值就会丢失，就需要在数据库启动以后重新设置。
   • 可以使用LAST_INSERT_ID()查询当前线程最后插入记录使用的值。如果一次插入了多条记录，那么返回的是第一条记录使用的自动增长值。
   • 自动增长列必须是索引。如果是组合索引，也必须是组合索引的第一列，但是对于MyISAM表，自动增长列可以是组合索引的其他列，这样插入记录后，自动增长列是按照组合索引前几列排序后在同值的类里面递值的。
   • 使用共享表存储，这种方式创建的表的表结构保存在.frm文件中，数据和索引保存在innodb_data_home_dir和innodb_data_file_path定义的表空间中，可以是多个文件。
   • 使用多表空间存储，这种方式创建的表的表结构仍然保存在.frm文件中，但是每个表的数据和索引单独保存在.idb中。
   • 多表空间的参数生效后，只对新建的表生效，其表的数据文件没有大小限制，不需要设置初始大小，也不需要设置文件的最大限制、扩展大小等参数。
6. MEMORY
   • 每个MEMORY表只实际对应一个磁盘文件，格式是.frm。MEMORY类型的表访问非常得快，因为它的数据是放在内存中的，并且默认使用HASH索引，但是一旦服务关闭，表中的数据就会丢失掉。
   • 每个MEMORY表中可以放置的数据量的大小，受到max_heap_table_size系统变量的約束，这个系统变量的初始值是16MB，可以按照需要加大。
7. MERGE
   • MERGE存储引擎是一组MyISAM表的组合，这些MyISAM表必须结构完全相同，MERGE表本身并没有数据，对MERGE类型的表可以进行查询、更新、删除的操作，这些操作实际上是对内部的实际的MyISAM表进行的。
   • MERGE表在磁盘上保留两个文件，文件名以表的名字开始，一个.frm文件存储表定义，另一个.MRG文件包含组合表的信息，包括MERGE表由哪些表组成、插入新的数据时的依据。可以通过修改.MRG文件来修改MERGE表，但是修改后要通过FLUSH TABLES刷新。

五、  字符集

1. 查看所有可用的字符集的命令是”show character set”或者”desc information_schema.character_sets”。
2. 字符集是用来定义MySQL存储字符串的方式，校对规则是定义了比较字符串的方式。
3. 每个字符集至少对应一个校对规则。可以用”show collation like ‘utf-8/gbk/***’”命令或者查看information_schema.COLLATIONS。
4. 校对规则命名约定：它们以其相关的字符集名开始，通常包括一个语言名，并且以_ci(大小写不敏感)、_cs(大小写敏感)或_bin(二元，即比较是基于字符编码的值而与language无关)结束。
5. MySQL的字符集和校对规则有４个级别的默认设置：服务器级、数据库级、表级和字段级。
6. 服务器字符集和校对，在MySQL服务启动的时候确定。可以在my.cnf中设置：default-character-set=gbk。或者在启动选项中指定：mysqld –default-character-set=gbk。或者在编译的时候指定：./configure –with-charaset=gbk。
7. 如果没有特别的指定服务器字符集，默认使用latin1作为服务器字符集。可以通过”show variables like ‘character_set_server’”和”show variables like ‘collation_server’”查看当前服务器的字符集和校对规则。
8. 数据库的字符集和校对规则在创建数据库的时候指定，如果没有指定，则应用服务器的字符集和校对规则的配置。要显示当前数据库的字符集和校对规则，可以使用”show variables like ‘character_set_database’”和”show variables like ‘collation_database’”命令查看。
9. 设置了以上４个级别的字符集，对于实际的应用访问来说，还存在客户端和服务器之间交互的字符集和校对规则的设置。对于客户端和服务器的交互操作，MySQL提供了３个不同的参数：character_set_client、character_set_connection和character_set_results，分别代表客户端、连接和返回結果的字符集。通过情况下，这３个字符集应该是相同的，才可以确保用户写入的数据可以正确地读出。
10. 可以通过”SET NAMES ***”来设置连接的字符集和校对规则，这个命令可以同时修改这３个参数的值。使用这个方法修改连接的字符集和校对规则，需要应用每次连接数据库后都执行这个命令。
11. 可以在my.cnf中设置”default-character-set=gbk”，这样服务器启动后，所有连接默认就是使用GBK字符集进行连接的，而不需要在程序中再执行set names命令了。