"\u003cp\u003e有一道面试题，是问“为什么在 MySQL 表里一定要有一个主键”。注意这里提到的主键包括用户自定义的主键ID或MySQL默认隐含添加的主键ID。\u003c/p\u003e\n\u003cp\u003e对于主键的设置，在日常开发中已经深深的刻在我们的大脑里，基本形成了肌肉记忆，于是在设置表结构时，对每个表必须手动设置一个主键，一般推荐使用自增的INT类型，且有时间还需要无业务逻辑。但如果突然遇到这个问题，一时还真不知道应该如何系统的回答。\u003c/p\u003e\n\u003cp\u003e下面我将根据自己的理解来分析一下，虽然可能并不完整，但应该可以成为一个及格的答案了。\n这里主要指的是InnoDB存储引擎，回答它可能需要从表引擎本身上下手。\u003c/p\u003e\n\u003ch2 id=\"存储结构\"\u003e存储结构\u003c/h2\u003e\n\u003cp\u003e首先我们知道在MySQL里的，InnoDB 是一个以“聚簇索引”组织数据进行存储，它是将主键与表数据存储在一起的。主键也是一种特殊的unique key，这个主键不可能重复（这句是废话）。一个主键就代表一条记录，也就是说，如果我们想找到一条记录，则必须根据主键才能找到对应的记录。如果没有这个唯一键，将无法对应多条记录，更不可能多条记录对应一个主键，或多个主键对应一条记录。\u003c/p\u003e\n\u003cp\u003e\u003cimg src=\"https://blogstatic.haohtml.com/uploads/2025/2319606-20220321160518273-1135088721.png\" alt=\"img\"\u003e\u003c/p\u003e\n\u003cp\u003e如图所示，蓝色字段是主键，绿色字段data就是记录数据，两者是一块 …\u003c/p\u003e"

"\u003ch2 id=\"innodb_ruby简介\"\u003einnodb_ruby简介\u003c/h2\u003e\n\u003cp\u003einnodb_ruby是一款用ruby写的用来分析 innodb 物理文件的专业DBA工具，可以通过这款工具来窥探innodb内部的一些结构。\n注意不要在生产环境中使用此工具，以避对线上服务造成影响。官方网址 \u003ca href=\"https://rubygems.org/gems/innodb_ruby\"\u003ehttps://rubygems.org/gems/innodb_ruby\u003c/a\u003e。\u003c/p\u003e\n\u003cp\u003e注意如果(Linux)平台安装中遇到错误一般情况是由于缺少依赖库造成的，可以先安装 sudo apt-get install libxslt1-dev libxml2-dev 相关库。\u003c/p\u003e\n\u003ch2 id=\"命令语法\"\u003e命令语法\u003c/h2\u003e\n\u003cp\u003e在执行以下命令时，建议切换到MySQL 的 datadir 目录里。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003esxf@ubuntu:~$ innodb_space --help\n\nUsage: innodb_space \u0026lt;options\u0026gt; \u0026lt;mode\u0026gt;\ninnodb_space \u0026lt;选项\u0026gt; \u0026lt;模式\u0026gt;\n命令主要分 options 和 mode 两大部分。\n\nInvocation examples:\n\n innodb_space -s ibdata1 [-T tname [-I …\u003c/code\u003e\u003c/pre\u003e"

"\u003ch2 id=\"一innodb-buffer-pool简介\"\u003e一、InnoDB Buffer Pool简介\u003c/h2\u003e\n\u003cp\u003eBuffer Pool是InnoDB引擎内存中的一块区域，主要用来缓存表和索引数据使用。我们知道从内存读取数据要比磁盘读取效率要高的多，这也正是buffer pool发挥的主要作用。一般配置值都比较大，在专用数据库服务器上，大小为物理内存的80%左右。\u003c/p\u003e\n\u003ch2 id=\"二buffer-pool-lru-算法\"\u003e二、Buffer Pool LRU 算法\u003c/h2\u003e\n\u003cp\u003eBuffer Pool 链表使用\u003cstrong\u003e优化改良后LRU\u003c/strong\u003e(最近最少使用)算法进行管理。\u003c/p\u003e\n\u003cp\u003e整个LRU链表可分为两个子链表，一个是New Sublist，也称为Young列表或新生代，另一个是Old Sublist ，称为Old 列表或老生代。每个子链表都有一个Head和Tail，中间部分是存储Page数据的地方。\u003c/p\u003e\n\u003cp\u003e当新的Page放入 Buffer Pool 缓存池的时候，会交其Page插入就是两个子链表的交界处，称为midpoint，同时就会有旧的Page被淘汰，整个操作过程都需要对链接进行维护。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eYoung 链表区存放的数据是经常访问的数据；\nOld 链表区存放是即将被淘汰的数据；\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e一个新数据先被插入到midpoint 位置，根据LRU算法访问频率高 …\u003c/p\u003e"

"\u003cp\u003e在MySQL8.0以前，索引使用规则有一项是索引左前缀，假如说有一个索引idx_abc(a,b,c)，能用到索引的情况只有查询条件为a、ab、abc、ac这四种，对于只有字段b的where条件是无法用到这个idx_abcf索引的。这里再强调一下，这里的顺序并不是在where中字段出现的顺序，where b=2 and 1=1 也是可以利用到索引的，只是用到了(a,b)这两个字段\u003c/p\u003e\n\u003cp\u003e针对这一点， 从MySQL 8.0.13开始引入了一种新的优化方案，叫做 \u003cstrong\u003eSkip Scan Range\u003c/strong\u003e，翻译过来的话是\u003cstrong\u003e跳跃范围扫描\u003c/strong\u003e。如何理解这个概念呢？我们可以拿官方的SQL示例具体讲一下（）\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eCREATE TABLE t1 (f1 INT NOT NULL, f2 INT NOT NULL, PRIMARY KEY(f1, f2));\nINSERT INTO t1 VALUES\n (1,1), (1,2), (1,3), (1,4), (1,5),\n (2,1), (2,2), (2,3), (2,4), (2,5);\nINSERT INTO t1 SELECT f1, f2 + 5 FROM t1; …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e在介绍InnoDB中的页的时候，很有必要先让大家了解一下InnoDB中的存储结构\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/innodb_engine_struct.png\" alt=\"\"\u003e\u003c/p\u003e\n\u003cp\u003e从InnoDB存储引擎的逻辑结构看，所有数据都被逻辑地存放在一个空间内，称为表空间(tablespace)，而表空间由段（sengment）、区（extent）、页（page）组成。 在一些文档中extend又称块（block）。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一、表空间（table space）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e表空间（Tablespace）是一个逻辑容器，表空间存储的对象是段，在一个表空间中可以有一个或多个段，但是一个段只能属于一个表空间。数据库由一个或多个表空间组成，表空间从管理上可以划分为系统表空间、用户表空间、撤销表空间、临时表空间等。\u003c/p\u003e\n\u003cp\u003e在 InnoDB 中存在两种表空间的类型：共享表空间和独立表空间。如果是共享表空间就意味着多张表共用一个表空间。如果是独立表空间，就意味着每张表有一个独立的表空间，也就是数据和索引信息都会保存在自己的表空间中。独立的表空间可以在不同的数据库之间进行迁移。可通过命令\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql \u0026gt; show variables like \u0026#39;innodb_file_per_table\u0026#39;;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e查看当前系统启用 …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"https://mp.weixin.qq.com/s/DHnGZroN36aC46Erzq6TWg\"\u003e新特新解读 | MySQL 8.0 对 count(*)的优化\u003c/a\u003e \u003ca href=\"https://mp.weixin.qq.com/s/ViGU5i5XlFjDTath_dh6pg\"\u003e新特性解读 | MySQL 8.0 正则替换\u003c/a\u003e \u003ca href=\"https://mp.weixin.qq.com/s/EOJ_jIhW07ifiYbpXs0lcQ\"\u003e新特性解读 | MySQL 8.0 资源组\u003c/a\u003e \u003ca href=\"https://mp.weixin.qq.com/s/4oUIW5_vWzWYAx_oMTwHOw\"\u003e新特性解读 | MySQL 8.0 Temptable 引擎介绍\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://mp.weixin.qq.com/s/Ocl2FTQ847Pwxtjp8N7L6w\"\u003e新特性解读 | MySQL 8.0 窗口函数详解\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://mp.weixin.qq.com/s/f-Za9y-6VsAs5VukyftqRA\"\u003e新特性解读 | MySQL 8.0 json到表的转换\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://mp.weixin.qq.com/s/ZJ9slZVAc5k1BYsX0id2Mg\"\u003e新特性解读 | MySQL 8.0.16 在组复制中启用成员自动重新加入\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://mp.weixin.qq.com/s/0NsfuTAVxCMRBz-NMQxA3Q\"\u003e新特性解读 | MySQL 8.0 直方图\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://mp.weixin.qq.com/s/aCe3UYnEnqGSE90bEFxxMg\"\u003e新特性解读 | MySQL 8.0 索引特性1-函数索引\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://mp.weixin.qq.com/s/J7LfZjhJak_rQ_Ft2sFmVQ\"\u003e新特性解读 | MySQL 8.0 索引特性2-索引跳跃扫描\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://mp.weixin.qq.com/s/_zTybsp6NQa_gbhGmCySvA\"\u003e新特性解读 | MySQL 8.0 索引特性3 -倒序索引\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://mp.weixin.qq.com/s/mdpZz9-Em1tQupK6ajYJJg\"\u003e新特性解读 | MySQL 8.0 索引特性4-不可见索引\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://mp.weixin.qq.com/s/GOw9Vb9iRV1r1IpvkTyHwQ\"\u003e新特性解读 | MySQL 8.0.16 组复制通讯协议的设置\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://mp.weixin.qq.com/s/U40BPB3N9jBx3NIKUhQXxA\"\u003e新特性解读 | MySQL 8.0.16 组复制新功能：消息碎片化\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003eMySQL 中的隔离四种隔离级别与锁的关系一直挺模糊的，看了好多文章感觉着都不是很好理解，今天在“\u003ca href=\"https://mp.weixin.qq.com/s/DhMy6fsdlFj3dGqRE_0JMg\"\u003e爱可生开源社区\u003c/a\u003e”看到一篇文章，感觉着挺容易理解的。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003ccode\u003eREAD UNCOMMITTED 未提交读，可以读取未提交的数据。\u003c/code\u003e\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eREAD COMMITTED 已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句， InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。\u003c/code\u003e Gap locking 仅用于外键约束检查和重复键检查。\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eREPEATABLE READ 可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。\u003c/code\u003e\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eSERIALIZABLE 序列化\u003c/code\u003e\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e文中主要对 RR 和 RC 两种常用的隔离级别做了不同情况的说明，对于 \u003ccode\u003eSERIALIZABLE 序列化\u003c/code\u003e 和 READ UNCOMMITTED 未提交读，由于很好理解所以未在文中体现。**对于 RR 和 RC 主要区别是 RR 存在 Gap Lock间隙锁，而RC则 …\u003c/p\u003e"

"\u003cp\u003e在MySQL5.7以前，ibdata1文件会逐渐增大（ \u003ca href=\"https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_ibdata_file\"\u003eibdata1文件包含哪些信息?\u003c/a\u003e），非常占用系统空间，特别是一些云数据来说，磁盘非常的贵，想要回收空间，只能进行一次导出和导入操作，来重新生成undo 表空间，从MySQL5.7开始，有了在线回收undo表空间的功能，主要由以下几个参数设置。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003einnodb_undo_directory = .\u003c/strong\u003e\n为undo文件存储路径。如果没有指定默认值(NULL)，则undo表空间则存放到mysql的data目录里(datadir选项)。配置此项可以用undo从ibdata文件里分离出来。单独存储。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003einnodb_undo_logs = 128\u003c/strong\u003e\n(默认值 128）undo rollback segment 回滚段个数，为 innodb_rollback_segments 参数选项的别名，最大值为128，其中32个为使用临时表空间 ibtmp1 保留，1个为系统表空间使用，剩余的95个为 undo tablespaces 使用。\n当 innodb_rollback_segments\u0026lt;=32的时候，系统将自动分配1个rollback …\u003c/p\u003e"

"\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://cloud.tencent.com/developer/article/1006514\"\u003ehttps://cloud.tencent.com/developer/article/1006514\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://yq.aliyun.com/articles/27667\"\u003ehttps://yq.aliyun.com/articles/27667\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"

"\u003cp\u003e**函数语法：\n**\u003c/p\u003e\n\u003cp\u003e**group_concat( [DISTINCT]  要连接的字段   [Order BY ****排序字段 **\u003cstrong\u003eASC/DESC]   [Separator ‘分隔符’] )\u003c/strong\u003e\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e\u003cstrong\u003e下面举例说明：\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eselect * from goods;\u003c/p\u003e\n\u003cp\u003e+——+——+\n| id| price|\n+——+——+\n|1 | 10|\n|1 | 20|\n|1 | 20|\n|2 | 20|\n|3 | 200 |\n|3 | 500 |\n+——+——+\n6 rows in set (0.00 sec)\u003c/p\u003e\n\u003chr\u003e\n\u003col\u003e\n\u003cli\u003e以id分组，把price字段的值在同一行打印出来，逗号分隔(默认)\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eselect id, group_concat(price) from goods group by id;\u003c/p\u003e\n\u003cp\u003e+——+——————–+\n| id| group_concat(price) |\n+——+——————–+\n|1 | 10,20,20|\n|2 | 20 |\n|3 | 200,500|\n+——+——————–+\n3 rows in set (0.00 sec)\u003c/p\u003e"

"\u003cp\u003e在开发过程时，我们经常会遇到 order by 排序操作，那么你知道什么时候MySQL才会进行排序操作，什么时候不需要时间排序操作？，下面我们就从一个很小的例子中了解一下排序场景。\u003c/p\u003e\n\u003cp\u003e表结构如下：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eCREATE TABLE t (\n id int(11) unsigned NOT NULL AUTO_INCREMENT,\n city varchar(16) NOT NULL,\n name varchar(16) NOT NULL,\n age int(11) NOT NULL,\n addr varchar(128) DEFAULT NULL,\n PRIMARY KEY (id),\n KEY city (city) USING BTREE\n ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e这里只有一个索引city，我们执行一条SQL语句：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eSELECT city, name FROM t WHERE city=\u0026#39;杭州\u0026#39; ORDER BY name LIMIT 1000;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e通过Explain命令查看执行情况\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/explain-1024x119.jpg\" alt=\"\"\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e …\u003c/p\u003e"

"\u003cp\u003eMySQL当前存在的三种复制模式有：异步模式、半同步模式和组复制模式。注意：MySQL复制模式没有“同步复制”这一项的，文章中只是为了读者方便理解半同步复制的概念才介绍了同步复制概念 \u003ca href=\"https://dev.mysql.com/doc/refman/8.0/en/replication-semisync.html\"\u003ehttps://dev.mysql.com/doc/refman/8.0/en/replication-semisync.html\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e从MySQL5.5开始，MySQL以插件的形式支持半同步复制。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1. 异步复制（Asynchronous replication）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eMySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。\u003c/p\u003e\n\u003cp\u003e异步复制是MySQL最早的也是当前使用最多的复制模式，异步复制提供了一种简单的主-从复制方法，包含一个主库（master）和备库（一个，或者多个） 之间，主库执行并提交了事务，在这之后（因此才称之为异步），这些事务才在从库上重新执行一遍（基于statement）或者变更数据内容（ …\u003c/p\u003e"

"\u003ch1 id=\"一mvcc简介\"\u003e一、MVCC简介\u003c/h1\u003e\n\u003cp\u003eMVCC (Multiversion Concurrency Control)，即多版本并发控制技术。InnoDB数据库的事务隔离级别就是通过UNDO和MVCC来实现的(ACID特性)，旧数据存储在UNDO中，再通过DB_ROLL_PTR 回溯查找历史版本。\u003c/p\u003e\n\u003ch1 id=\"二mvcc原理\"\u003e二、MVCC原理\u003c/h1\u003e\n\u003cp\u003e1、通过DB_ROLL_PT 回溯查找数据历史版本2、通过read view判断行记录是否可见\u003c/p\u003e\n\u003cp\u003e理解这一块之前，我们必须先了解一下row的内部存储格式\u003c/p\u003e\n\u003cp\u003e\u003cimg src=\"https://blog--static.oss-cn-shanghai.aliyuncs.com//uploads/2023/09/image-20230904183143992.png\" alt=\"image-20230904183143992\"\u003e\u003c/p\u003e\n\u003cp\u003e字段\b说明：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDB_ROW_ID：\u003cstrong\u003e长度6个字节。此值由\u003c/strong\u003eInnoDB自动生成\u003c/strong\u003e，聚集索引时使用。如果用户未显式指定表主键时，\u001b表优先使用\u003cstrong\u003e第一个非null的唯一索引\u003c/strong\u003e作为主键.否则使用DB_ROW_ID的值作为主键ID，聚集索引会使用此值。如果指定了表主键的话，则聚集索引使用指定的值。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDB_TRX_ID：\u003cstrong\u003e6个字节的事务ID。标记了最后\u003c/strong\u003e更新\u003c/strong\u003e此记录的事务ID，每开起一个新事务，其值自动+1\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDB_ROLL_PTR：\u003cstrong\u003e7字节的回滚指针。指向当前记录项的\u003c/strong\u003eundo log\u003c/strong\u003e记录，找之前版本的数据需通过此指针。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eMySQL中的MVCC原理\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://blog.haohtml.com/wp-content/uploads/2018/09/mysql_mvcc_3.24.44.png\"\u003e\u003cimg src=\"https://blog--static.oss-cn-shanghai.aliyuncs.com//uploads/2023/09/mysql_mvcc_3.24.44.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e首次 \u003ccode\u003einsert\u003c/code\u003e\u003c/strong\u003e …\u003c/p\u003e"

"\u003ch1 id=\"index-condition-pushdownicp\"\u003eIndex Condition Pushdown(ICP)\u003c/h1\u003e\n\u003cp\u003eIndex Condition Pushdown (ICP)是mysql使用索引从表中检索行数据的一种优化方式。\u003c/p\u003e\n\u003ch3 id=\"icp原理\"\u003eICP原理\u003c/h3\u003e\n\u003cp\u003e禁用ICP，存储引擎会通过遍历索引定位基表中的行，然后返回给MySQL Server层，再去为这些数据行进行WHERE后的条件的过滤。\u003c/p\u003e\n\u003cp\u003e开启ICP，如果部分WHERE条件能使用索引中的字段，MySQL Server 会把这部分下推到存储引擎层，存储引擎通过索引过滤，把满足的行从表中读取出。ICP能减少引擎层访问基表的次数和MySQL Server 访问存储引擎的次数。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eICP的目标是减少从基表中全纪录读取操作的数量，从而降低IO操作\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e对于InnoDB表，ICP只适用于辅助索引。\u003c/p\u003e\n\u003ch3 id=\"icp标识\"\u003eICP标识\u003c/h3\u003e\n\u003cp\u003e当使用ICP优化时，执行计划的Extra列显示 \u003cstrong\u003eUsing index condition\u003c/strong\u003e提示\u003c/p\u003e\n\u003ch3 id=\"相关参数\"\u003e相关参数\u003c/h3\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eoptimizer_switch=\u0026#34;index_condition_pushdown=on”;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e可以通过 SET optimizer_switch = …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"https://www.jianshu.com/p/0371c9569736\"\u003ehttps://www.jianshu.com/p/0371c9569736\u003c/a\u003e\u003c/p\u003e"

"\u003ch2 id=\"一innodb_file_format参数\"\u003e一：innodb_file_format参数\u003c/h2\u003e\n\u003cp\u003e在 innodb 1.0.6版本之前，innodb文件格式\u003ccode\u003einnodb_file_format\u003c/code\u003e只有 Antelope(Antelope 文件格式支持Redundant，Compact两种格式来存放行记录，Redundant是为了兼容之前版本而保留的。在mysql 5.1版本中，默认设置为Compact，用户可以通过 \u003ccode\u003eshow table status like 'table_name'\u003c/code\u003e来查看表使用的行格式row_format)\u003c/p\u003e\n\u003cp\u003e从innodb 1.0.6开始引入了新的文件格式 Barracuda 在原来的基础上(Antelope)新增了Dynamic和Compressed两种行格式。\u003c/p\u003e\n\u003ch2 id=\"二innodb_file_format如何使用\"\u003e二：innodb_file_format如何使用\u003c/h2\u003e\n\u003cp\u003e  一般， \u003ccode\u003einnodb_file_format\u003c/code\u003e 在配置文件中指定；\u003ccode\u003erow_format\u003c/code\u003e则在创建数据表时指定：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eCREATE TABLE test2 (column1 INT PRIMARY KEY)\nENGINE=InnoDB ROW_FORMAT=Compressed KEY_BLOCK_SIZE=4;\n\u003c/code\u003e\u003c/pre\u003e\u003ch2 id=\"三innodb_file_format--barracuda\"\u003e …\u003c/h2\u003e"

"\u003cp\u003e推荐阅读： \u003ca href=\"https://www.cnblogs.com/zishengY/p/6892345.html\"\u003ehttps://www.cnblogs.com/zishengY/p/6892345.html\u003c/a\u003e\u003c/p\u003e"

"\u003ch2 id=\"一什么是mrr\"\u003e**一、什么是MRR **\u003c/h2\u003e\n\u003cp\u003eMMR全称是Multi-Range Read，是MYSQL5.6优化器的一个新特性，在MariaDB5.5也有这个特性。优化的功能在使用二级索引做范围扫描的过程中减少磁盘随机IO和减少主键索引的访问次数。\u003cstrong\u003e是优化器将随机 IO 转化为顺序 IO 以降低查询过程中 IO 开销的一种手段。\u003c/strong\u003e（参考： \u003ca href=\"https://blog.csdn.net/caomiao2006/article/details/52205177\"\u003ehttps://blog.csdn.net/caomiao2006/article/details/52205177\u003c/a\u003e）\u003c/p\u003e\n\u003ch2 id=\"二mrr和没有mrr的区别\"\u003e**二、MRR和没有MRR的区别 **\u003c/h2\u003e\n\u003cp\u003e给出一个简单的例子，在innodb表执行下面的查询：\u003c/p\u003e\n\u003cp\u003eSELECT non_key_column FROM tbl WHERE key_column=x\u003c/p\u003e\n\u003cp\u003e在没有MRR的情况下，它是这样得到结果的：\u003c/p\u003e\n\u003cp\u003e1.  select key_column, pk_column from tb where key_column=x order  by key_column —\u0026gt;\n假设这个结果集是t\u003c/p\u003e\n\u003cp\u003e2.  for each row in t ;\nselect non_key_column from tb where …\u003c/p\u003e"

"\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e注意: FOR UPDATE 只能用在事务区块(BEGIN/COMMIT)中才有效。\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e有时候我们会看到一些select语句后面紧跟一句for update，表示手动加锁的意思，这里我们就介绍一下对for update的理解。相对另一种手动加锁方法lock in share mode 的区别见： \u003ca href=\"https://blog.csdn.net/liangzhonglin/article/details/65438777\"\u003ehttps://blog.csdn.net/liangzhonglin/article/details/65438777\u003c/a\u003e。\u003c/p\u003e\n\u003cp\u003efor update：IX锁(意向排它锁)，即在符合条件的rows上都加了排它锁，其他session也就无法在这些记录上添加任何的S锁或X锁。如果不存在一致性非锁定读的话，那么其他session是无法读取和修改这些记录的，但是innodb有非锁定读(快照读并不需要加锁)，for update之后并不会阻塞其他session的快照读取操作，除了select …lock in share mode和select … for update这种显示加锁的查询操作。\u003c/p\u003e\n\u003cp\u003elock in share mode：是IS锁(意向共享锁)，即在符合条件的rows上都加了共享锁，这样的话，其 …\u003c/p\u003e"

"\u003cp\u003e建议先阅读这篇文章： \u003ca href=\"http://hidba.org/?p=404\"\u003ehttp://hidba.org/?p=404\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e下面我们只对其中提到的做一个验证。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e(1).索引字段的附加信息：可以分为变长和定长数据类型讨论，当索引字段为定长数据类型，比如\u003cstrong\u003echar\u003c/strong\u003e，\u003cstrong\u003eint\u003c/strong\u003e，\u003cstrong\u003edatetime\u003c/strong\u003e，需要有是否为空的标记，这个标记需要占用1个字节；对于变长数据类型，比如：varchar，除了是否为空的标记外，还需要有长度信息，需要占用2个字节；\u003c/p\u003e\n\u003cp\u003e(备注：当字段定义为非空的时候，是否为空的标记将不占用字节)\u003c/p\u003e\n\u003cp\u003e(2).同时还需要考虑表所使用的字符集，不同的字符集，gbk编码的为一个字符2个字节，utf8编码的一个字符3个字节， utf8mb4 编码则是4个字节;\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e每种MySQL数据类型的定义参考：\u003c/p\u003e\n\u003cp\u003e下面我们以定长数据类型准，变长数据类型请自行测试。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一、数据索引类型允许为null的情况：\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e表结构：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eCREATE TABLE `tb` (\n`id` int(10) unsigned NOT NULL AUTO_INCREMENT,\n`sid` smallint(5) DEFAULT NULL,\n`gid` smallint(5) DEFAULT NULL, …\u003c/code\u003e\u003c/pre\u003e"

"\u003ch1 id=\"index-condition-pushdownicp\"\u003eIndex Condition Pushdown(ICP)\u003c/h1\u003e\n\u003cp\u003eIndex Condition Pushdown (ICP)是mysql使用索引从表中检索行数据的一种优化方式。\u003c/p\u003e\n\u003ch3 id=\"icp原理\"\u003eICP原理\u003c/h3\u003e\n\u003cp\u003e禁用ICP，存储引擎会通过遍历索引定位基表中的行，然后返回给MySQL Server层，再去为这些数据行进行WHERE后的条件的过滤。\u003c/p\u003e\n\u003cp\u003e开启ICP，如果部分WHERE条件能使用索引中的字段，MySQL Server 会把这部分下推到存储引擎层，存储引擎通过索引过滤，把满足的行从表中读取出。ICP能减少引擎层访问基表的次数和MySQL Server 访问存储引擎的次数。\u003c/p\u003e\n\u003cp\u003eICP的目标是减少从基表中全纪录读取操作的数量，从而降低IO操作\u003c/p\u003e\n\u003cp\u003e对于InnoDB表，ICP只适用于辅助索引。\u003c/p\u003e\n\u003ch3 id=\"icp标识\"\u003eICP标识\u003c/h3\u003e\n\u003cp\u003e当使用ICP优化时，执行计划的Extra列显示Using indexcondition提示\u003c/p\u003e\n\u003ch3 id=\"相关参数\"\u003e相关参数\u003c/h3\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eoptimizer_switch=\u0026#34;index_condition_pushdown=on”;\n\u003c/code\u003e\u003c/pre\u003e\u003ch3 id=\"适用场景\"\u003e适用场景\u003c/h3\u003e\n\u003cp\u003e#辅助索引INDEX (\u003ccode\u003ezipcode\u003c/code\u003e, \u003ccode\u003elastname\u003c/code\u003e, \u003ccode\u003efirstname\u003c/code\u003e).\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eSELECT * …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e错误信息\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eSQLSTATE[HY000] [2054] The server requested authentication method unknown to…\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e这个错可能是mysql默认使用 \u003ccode\u003ecaching_sha2_password\u003c/code\u003e 作为默认的身份验证插件，而不再是 \u003ccode\u003emysql_native_password\u003c/code\u003e，但是客户端暂时不支持这个插件导致的。 \u003ca href=\"https://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.html\"\u003e官方文档说明\u003c/a\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eIn MySQL 8.0, caching_sha2_password is the default authentication plugin rather than mysql_native_password. For information about the implications of this change for server operation and compatibility of the server with clients and connectors, see caching_sha2_password as the Preferred Authentication Plugin.\u003c/p\u003e\n\u003cp\u003e …\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cp\u003eMySQL使用基于 \u003cstrong\u003e成本的优化器\u003c/strong\u003e，它尝试预测一个查询使用某种执行计划时的成本，并选择其中成本最小的一个。在MySQL可以通过查询当前会话的 \u003ccode\u003elast_query_cost\u003c/code\u003e 的值来得到其计算当前查询的成本。\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;\"\u003e\u003ccode class=\"language-sql\" data-lang=\"sql\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003emysql\u003cspan style=\"color:#f92672\"\u003e\u0026gt;\u003c/span\u003e \u003cspan style=\"color:#66d9ef\"\u003eselect\u003c/span\u003e \u003cspan style=\"color:#f92672\"\u003e*\u003c/span\u003e \u003cspan style=\"color:#66d9ef\"\u003efrom\u003c/span\u003e t_message \u003cspan style=\"color:#66d9ef\"\u003elimit\u003c/span\u003e \u003cspan style=\"color:#ae81ff\"\u003e10\u003c/span\u003e;\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e...\u003cspan style=\"color:#960050;background-color:#1e0010\"\u003e省略结果集\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003emysql\u003cspan style=\"color:#f92672\"\u003e\u0026gt;\u003c/span\u003e \u003cspan style=\"color:#66d9ef\"\u003eshow\u003c/span\u003e status \u003cspan style=\"color:#66d9ef\"\u003elike\u003c/span\u003e \u003cspan style=\"color:#e6db74\"\u003e\u0026#39;last_query_cost\u0026#39;\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#f92672\"\u003e+\u003c/span\u003e\u003cspan style=\"color:#75715e\"\u003e-----------------+-------------+\n\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#75715e\"\u003e\u003c/span\u003e\u003cspan style=\"color:#f92672\"\u003e|\u003c/span\u003e Variable_name \u003cspan style=\"color:#f92672\"\u003e|\u003c/span\u003e Value \u003cspan style=\"color:#f92672\"\u003e|\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#f92672\"\u003e+\u003c/span\u003e\u003cspan style=\"color:#75715e\"\u003e-----------------+-------------+\n\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#75715e\"\u003e\u003c/span\u003e\u003cspan style=\"color:#f92672\"\u003e|\u003c/span\u003e Last_query_cost\u003cspan style=\"color:#f92672\"\u003e|\u003c/span\u003e \u003cspan style=\"color:#ae81ff\"\u003e6391\u003c/span\u003e.\u003cspan style=\"color:#ae81ff\"\u003e799000\u003c/span\u003e \u003cspan style=\"color:#f92672\"\u003e|\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e\u003cspan style=\"color:#f92672\"\u003e+\u003c/span\u003e\u003cspan style=\"color:#75715e\"\u003e-----------------+-------------+\n\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e示例中的结果表示优化器认为大概需要做6391个数据页的随机查找才能完成上面的查询。这个结果是根据一些列的统计信息计算得来的，这些统计信息包括： \u003cstrong\u003e每张表或者索引的页面个数\u003c/strong\u003e、 \u003cstrong\u003e索引的基数\u003c/strong\u003e、 \u003cstrong\u003e索引\u003c/strong\u003e 和 \u003cstrong\u003e数据行的长度\u003c/strong\u003e、 \u003cstrong\u003e索引的分布\u003c/strong\u003e 情况等等。\u003c/p\u003e\n\u003cp\u003e有非常多 …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"https://dev.mysql.com/doc/refman/5.7/en/charset.html\"\u003ehttps://dev.mysql.com/doc/refman/5.7/en/charset.html\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e平时我们只说了字符集这个概念，另外还有对应的“\u003cstrong\u003e字符序\u003c/strong\u003e”。一个字符集(如utf8)对应多个字符序(utf8_general_ci、utf8_german2_ci等），每个\u003cstrong\u003e字符集\u003c/strong\u003e都有一个默认“\u003cstrong\u003e字符序\u003c/strong\u003e”。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e什么是字符集、字符序？简单的来说：\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e字符集（character set）：定义了字符以及字符的存储编码。\u003c/li\u003e\n\u003cli\u003e字符序（collation）：定义了字符的比较规则。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e可以通过命令查看字符集、字符序信息：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eSHOW CHARACTER SET;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e在我们开发中，一般要保持服务器端的字符集与客户端的字符集保持一致，不然容易出现乱码的情况。\u003c/p\u003e\n\u003cp\u003eMySQL提供了不同级别的设置，包括\u003cstrong\u003eserver\u003c/strong\u003e级、\u003cstrong\u003edatabase\u003c/strong\u003e级、\u003cstrong\u003etable\u003c/strong\u003e级、\u003cstrong\u003ecolumn\u003c/strong\u003e级，可以提供非常精准的设置。\u003c/p\u003e\n\u003cp\u003e参考文章： \u003ca href=\"https://www.cnblogs.com/chyingp/p/mysql-character-set-collation.html\"\u003ehttps://www.cnblogs.com/chyingp/p/mysql-character-set-collation.html\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e官方文档： \u003ca href=\"https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sql-mode-setting\"\u003ehttps://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sql-mode-setting\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一、模式分类\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e在MySQL8.0中主要包括以下几种模式\u003c/p\u003e\n\u003ctable\u003e\n \u003cthead\u003e\n \u003ctr\u003e\n \u003cth\u003e\u003cstrong\u003eONLY_FULL_GROUP_BY\u003c/strong\u003e\u003c/th\u003e\n \u003cth\u003e对于GROUP BY聚合操作，如果在SELECT中的列，没有在GROUP BY中出现，那么将认为这个SQL是不合法的，因为列不在GROUP BY从句中\u003c/th\u003e\n \u003c/tr\u003e\n \u003c/thead\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd\u003e\u003cstrong\u003eSTRICT_TRANS_TABLES\u003c/strong\u003e\u003c/td\u003e\n \u003ctd\u003e在该模式下，如果一个值不能插入到一个事务表中，则中断当前的操作，对非事务表不做任何限制\u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd\u003e\u003cstrong\u003eNO_ZERO_IN_DATE\u003c/strong\u003e\u003c/td\u003e\n \u003ctd\u003e在严格模式，不接受月或日部分为0的日期。如果使用IGNORE选项，我们为类似的日期插入’0000-00-00’。在非严格模式，可以接受该日期，但会生成警告。\u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd\u003e\u003cstrong\u003eNO_ZERO_DATE …\u003c/strong\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e"

"\u003cp\u003e\u003cstrong\u003e一、为什么要用小表驱动大表\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e1、驱动表的定义\u003c/p\u003e\n\u003cp\u003e当进行多表连接查询时， [驱动表] 的定义为：\u003c/p\u003e\n\u003cp\u003e1）指定了联接条件时，满足查询条件的记录行数少的表为[驱动表]\u003c/p\u003e\n\u003cp\u003e2）未指定联接条件时，行数少的表为[驱动表]（重要）\u003c/p\u003e\n\u003cp\u003e忠告：如果你搞不清楚该让谁做驱动表、谁 join 谁，请让 MySQL 运行时自行判断\u003c/p\u003e\n\u003cp\u003e既然“未指定联接条件时，行数少的表为[驱动表]”了，而且你也对自己写出的复杂的 Nested Loop Join 不太有把握（如下面的实例所示），就别指定谁 left/right join 谁了，请交给 MySQL优化器 运行时决定吧。\u003c/p\u003e\n\u003cp\u003e2、mysql关联查询的概念:\u003c/p\u003e\n\u003cp\u003eMySQL 表关联的算法是 \u003ca href=\"http://lizhen3708693.iteye.com/blog/1631406\"\u003eNest Loop Join(嵌套循环)\u003c/a\u003e，是通过驱动表的结果集作为循环基础数据，然后一条一条地通过该结果集中的数据作为过滤条件到下一个表中查询数据，然后合并结果。\u003c/p\u003e\n\u003cp\u003e例: user表10000条数据，class表20条数据\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eSELECT * FROM user u LEFT JOIN class c u.userid=c.userid\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e这样则需要用user表循环10000次才能查询出来，而如果 …\u003c/p\u003e"

"\u003cp\u003eInnoDB是一个支持行锁的存储引擎，锁的类型有：共享锁（S）、排他锁（X）、意向共享（IS）、意向排他（IX）。为了提供更好的并发，InnoDB提供了非锁定读：不需要等待访问行上的锁释放，读取行的一个快照。该方法是通过InnoDB的一个特性：MVCC来实现的。\u003c/p\u003e\n\u003ch1 id=\"innodb有三种行锁的算法\"\u003e\u003cstrong\u003eInnoDB有三种行锁的算法\u003c/strong\u003e\u003c/h1\u003e\n\u003cp\u003e1，Record Lock：单个行记录上的锁。\u003c/p\u003e\n\u003cp\u003e2，Gap Lock：间隙锁，锁定一个范围，但不包括记录本身。GAP锁的目的，是为了防止同一事务的两次当前读，出现幻读的情况。\u003c/p\u003e\n\u003cp\u003e3，Next-Key Lock：1+2，锁定一个范围，并且锁定记录本身。对于行的查询，都是采用该方法，主要目的是解决幻读的问题。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e锁的是索引，并不是记录。\u003c/strong\u003e\n记录锁（Record Lock): 单个索引行记录上的锁\n间隙锁（Gap Lock）:一般是针对非唯一索引而言的.\n后码锁（Next-Key Lock）:记录锁和间隙锁的结合，对于InnoDB中，更新\u003cstrong\u003e非唯一索引\u003c/strong\u003e对应的记录，会加上Next-Key Lock。在RR下如果where未使用索引会使用全表扫描，这个时候会有Next-Key  Lock。如果更新记录为空，就不能加记 …\u003c/p\u003e"

"\u003cp\u003emyisam的主索引和次索引都指向物理行，下面来进行讲解\u003c/p\u003e\n\u003cp\u003einnodb的主键下存储该行的数据，此索引指向对主键的引用\u003c/p\u003e\n\u003cp\u003emyisam的索引存储图如下，可以看出，无论是id还是cat_id，\u003cstrong\u003e下面都存储有存储物理地址的值。通过主键索引或者次索引来查询数据的时候，都是先查找到\u001b数据地址，然后再到物理位置上去寻找数据\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e[\u003cimg src=\"https://blog--static.oss-cn-shanghai.aliyuncs.com//uploads/2023/09/myisam-index-struct.png\" alt=\"\"\u003e][1]\u003c/p\u003e\n\u003cp\u003einnodb的索引存储图如下，我们会发现，\u003cstrong\u003e主键索引下面直接存储有数据，而次索引下，存储的是主键的id(不同于MyISAM，存储的是内容数据的物理地址）\u003c/strong\u003e。通过主键查找数据的时候，就会很快查找到数据，但是通过次索引查找数据的时候，需要先查找到对应的主键id，然后才能查找到对应的数据。\u003c/p\u003e\n\u003cp\u003e[\u003cimg src=\"https://blog--static.oss-cn-shanghai.aliyuncs.com//uploads/2023/09/innodb-index-struct.png\" alt=\"\"\u003e][2]\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e总结：\u003c/strong\u003e\nInnoDB的主索引文件上 直接存放该行数据,称为聚簇索引,次索引指向对\u003cstrong\u003e主键的引用\u003c/strong\u003e.\nMyisam中, 主索引和次索引,都指向物理行(\u003cstrong\u003e磁盘位置\u003c/strong\u003e).\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e注意:对InnoDB来说,\u003c/strong\u003e\n1: 主键索引 既存储索引值,又在叶子中存储行的数据\n2: 如果没有主键, 则会Unique key做主键\n3: 如果没有unique,则系统生成一个内部的rowid做主键.\n4: \u003cstrong\u003e像innodb …\u003c/strong\u003e\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"http://www.cnblogs.com/freespider/p/5425172.html\"\u003ehttp://www.cnblogs.com/freespider/p/5425172.html\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://88250.b3log.org/backup-mysql-shell\"\u003ehttp://88250.b3log.org/backup-mysql-shell\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"http://www.ruzuojun.com/topic/420.html\"\u003ehttp://www.ruzuojun.com/topic/420.html\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e这周阿里集团DBA内部分享时，支付宝的黄忠同学提了一个问题，关于InnoDB索引page 的利用率。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e\u003cstrong\u003epage********利用率\u003c/strong\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e主要是指btee里面每个page的使用被使用的空间大小。我们知道InnoDB默认一个page大小是16k。但实际使用情况不会总用满\u003c/p\u003e\n\u003cp\u003e我们定义为所有page的总使用字节除以总字节数。\u003c/p\u003e\n\u003cp\u003e在理论分析之前，我们要先弄个工具，查一下。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e\u003cstrong\u003e实例统计\u003c/strong\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e写了一个简单的工具，读ibd文件上的每个page，算出每个page的实际使用字节，可以得到利用率。\u003c/p\u003e\n\u003cp\u003e我们找了线上一个库来模拟。表中有1个自增主键和3个非聚簇索引。不影响结论地简化为如下：\u003c/p\u003e\n\u003cp\u003eCREATE TABLE \u003ccode\u003ectu_factor_risk_99_03\u003c/code\u003e (\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eseq_id\u003c/code\u003e bigint(20) unsigned NOT NULL AUTO_INCREMENT,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ea\u003c/code\u003e varchar(32) DEFAULT NULL,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eb\u003c/code\u003e varchar(32) DEFAULT NULL,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ec\u003c/code\u003e varchar(32) DEFAULT NULL,\u003c/p\u003e\n\u003cp\u003eKEY a (a),\u003c/p\u003e\n\u003cp\u003eKEY bc (b,c),\u003c/p\u003e\n\u003cp\u003eKEY cb (c,b),\u003c/p\u003e\n\u003cp\u003e) …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"http://dinglin.iteye.com/blog/1682188\"\u003ehttp://dinglin.iteye.com/blog/1682188\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e上一篇我们介绍了ibd_used这个工具，我们用来量化看表数据文件的page使用率。这里用来说明optimize table这个命令的问题和优化。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e\u003cstrong\u003e实例准备\u003c/strong\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e建一个这样的表\u003c/p\u003e\n\u003cp\u003eCREATE TABLE \u003ccode\u003etb\u003c/code\u003e (\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eseq_id\u003c/code\u003e bigint(20) unsigned NOT NULL AUTO_INCREMENT,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ea\u003c/code\u003e varchar(32) DEFAULT NULL,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eb\u003c/code\u003e varchar(32) DEFAULT NULL,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ec\u003c/code\u003e varchar(32) DEFAULT NULL,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ed\u003c/code\u003e char(255) DEFAULT NULL,\u003c/p\u003e\n\u003cp\u003ePrimary key (seq_id),\u003c/p\u003e\n\u003cp\u003eKEY a (a),\u003c/p\u003e\n\u003cp\u003eKEY bc (b,c),\u003c/p\u003e\n\u003cp\u003eKEY cb (c,b)\u003c/p\u003e\n\u003cp\u003e) ENGINE=InnoDB DEFAULT CHARSET=utf8;\u003c/p\u003e\n\u003cp\u003e执行语句为“insert into tb(a,b,c) values(randstr, randstr, randstr);” randstr是客户端程序生成的长度30字节的随机字符串。30个线程并发，每个线程插入1w条记录。\u003c/p\u003e\n\u003cp\u003e等待更新完成后（包括purge完成，从系统 …\u003c/p\u003e"

"\u003cp\u003e有同学问到InnoDB的索引长度问题，简单说几个tips。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e关于3072\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e大家经常碰到InnoDB单列索引长度不能超过767bytes，实际上联合索引还有一个限制是3072。\u003c/p\u003e\n\u003cp\u003e[\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/19130103_qFJc.jpg\" alt=\"\"\u003e][1]\u003c/p\u003e\n\u003cp\u003e可以看到，由于每个字段占用255*3, 因此这个索引的大小是3825(255*3*5)\u0026gt;3072，报错。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e为什么3072\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e我们知道InnoDB一个page的默认大小是16k。由于是Btree组织，要求叶子节点上一个page至少要包含两条记录（否则就退化链表了）。\u003c/p\u003e\n\u003cp\u003e所以一个记录最多不能超过8k。\n又由于InnoDB的聚簇索引结构，一个二级索引要包含主键索引，因此每个单个索引不能超过4k （极端情况，pk和某个二级索引都达到这个限制）。\n由于需要预留和辅助空间，扣掉后不能超过3500，取个“整数”就是(1024*3)。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e单列索引限制\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e上面有提到单列索引限制767，起因是256×3-1。这个3是字符最大占用空间（utf8）。但是在5.6以后，开始支持4个字节的uutf8。255×4\u0026gt;767, 于是增加了一个参数叫做 innodb_large_prefix。\u003c/p\u003e\n\u003cp\u003e这个参数默认值是OFF。当改为ON时， …\u003c/p\u003e"

"\u003ch2 id=\"activity-name.rich_media_title\"\u003e\u003ca href=\"http://mp.weixin.qq.com/s/osxa_3lFfL_H934dVm6Ttg\"\u003e由浅入深理解InnoDB的索引实现(1)\u003c/a\u003e\u003c/h2\u003e\n\u003ch2 id=\"activity-name.rich_media_title\"\u003e\u003ca href=\"https://mp.weixin.qq.com/s/FcizTIjPZ40jFJPqTsit8A\"\u003e由浅入深理解InnoDB的索引实现(2)\u003c/a\u003e\u003c/h2\u003e"

"\u003ch2 id=\"activity-name.rich_media_title\"\u003e\u003ca href=\"https://mp.weixin.qq.com/s/FSxy3Dlxvl3q416zZfBuuQ\"\u003eMySQL数据库InnoDB存储引擎Log漫游(1)\u003c/a\u003e\u003c/h2\u003e\n\u003ch2 id=\"activity-name.rich_media_title\"\u003e\u003ca href=\"https://mp.weixin.qq.com/s/R8G5mqX57XobXFDVFSsNdw\"\u003eMySQL数据库InnoDB存储引擎Log漫游(2)\u003c/a\u003e\u003c/h2\u003e\n\u003ch2 id=\"activity-name.rich_media_title\"\u003e\u003ca href=\"http://mp.weixin.qq.com/s/OyC3QfIW2N-_I8SS-HS0Gw\"\u003eMySQL数据库InnoDB存储引擎Log漫游(3)\u003c/a\u003e\u003c/h2\u003e\n\u003cp\u003e以上转自 \u003cem\u003e宋利兵\u003c/em\u003e 老师的公众号“\u003cstrong\u003eMySQL代码研究\u003c/strong\u003e”\u003c/p\u003e"

"\u003cp\u003e在5.6以后，可以通过命令动态修改.\u003c/p\u003e\n\u003cp\u003e注意有些命令是需要主从都要执行，有些命令是只在slave执行。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003egtid_mode 的几种状态值说明：\u003c/strong\u003e\nOFF: 不产生 GTID, 基于 binlog+position,也不能接受GTID的日志。默认值\nOFF_PERMISSIVE:  不生产 GTID,但作为slave可以识别GTID事务也可以识别非GTID事务\nON_PERMISSIVE: 产生GTID，slave可以处理GTID事务和非GTID事务\nON: 产生GTID事务，slave只接受GTID事务\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e实验一：将传统复制切换到GTID复制\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e启用GTID:\u003c/strong\u003e\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eset @@global.enforce_gtid_consitency=warn;\nset @@global.enforce_gtid_consistency=on;\nset @@global.gtid_mode=OFF_PERMISSIVE; #不产生gtid,但可以处理gtid\nset @@global.gtid_mode=ON_PERMISSIVE; #产生gtid,也可以处理gtid\nshow status like …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e在5.7下半同步是以插件的形式出现的，所以在启用半同步前要先安装半同步插件 semisync_master.so\u003c/p\u003e\n\u003cp\u003eOn the master:\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eINSTALL PLUGIN rpl_remi_sync_master SONAME \u0026#39;semisync_master.so\u0026#39;;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eOn slave slave:\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eINSTALL PLUGIN rpl_semi_sync_slave SONAME \u0026#39;semisync_slave.so\u0026#39;;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e在my.cnf里配置,要写在mysqld段\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003emaster:\u003c/strong\u003e\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e[mysqld]\nrepl_semi_sync_master_enable=1\nrepl_semi_sync_master_timeout=1000 #1 second\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e\u003cstrong\u003eslave:\u003c/strong\u003e\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e[mysqld]\nrepl_semi_sync_slave_enable=1\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e卸载插件：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003euninstall plugin rpl_semi_sync_master; # master\nuninstall plugin rpl_semi_sync_slave; # slave\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e在主上设 …\u003c/p\u003e"

"\u003cp\u003e架构为两主一从，两主为同一台服务器的多实例，安装方法请参考上篇文章 \u003ca href=\"http://blog.haohtml.com/archives/17300\"\u003ehttp://blog.haohtml.com/archives/17300\u003c/a\u003e。\u003c/p\u003e\n\u003cp\u003e主master1    IP: 192.168.1.116     PORT: 3306\n主master2    IP: 192.168.1.116     PORT: 3307\n从slave        IP: 192.168.1.200     PORT: 3306\u003c/p\u003e\n\u003cp\u003e两主为全新安装。如果以前安装过的话，可以将原来的数据库删除掉，再执行 \u003ccode\u003ereset master\u003c/code\u003e 即可。(否则需要将两个主的想着库表使用 mysqldump到从中) \u003ccode\u003emy.cnf \u003c/code\u003e配置\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e[master1 3306] \n[client]\nport=3306\nsocket=/data/mysql/mysql3306/tmp/mysql.sock\n\n[mysqld]\nbasedir=/data/mysql/mysql3306\ndatadir=/data/mysql/mysql3306/datadir\n#socket=/var/lib/mysql/mysql.sock …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e\u003ca href=\"http://www.cnblogs.com/gomysql/p/3650645.html\"\u003ehttp://www.cnblogs.com/gomysql/p/3650645.html\u003c/a\u003e\u003c/p\u003e"

"\u003col\u003e\n\u003cli\u003e一个存放记录(row)的page，由page header、page trailer、page body组成。如下图:\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2017/01/page_struct.png\"\u003e2\u003c/a\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2017/01/page_struct.png\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/page_struct.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003epage的完整结构\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2017/01/page_full_struct.jpg\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/page_full_struct.jpg\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003epage的结构详情参看如下：\u003c/p\u003e\n\u003cp\u003efrom: \u003ca href=\"http://forge.mysql.com/wiki/MySQL_Internals_InnoDB#InnoDB_Page_Structure\"\u003ehttp://forge.mysql.com/wiki/MySQL_Internals_InnoDB#InnoDB_Page_Structure\u003c/a\u003e High-Altitude Picture\u003c/p\u003e\n\u003cp\u003eThe chart below shows the three parts of a physical record.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eName****Size\u003c/strong\u003e\nField Start Offsets\u003c/p\u003e\n\u003cp\u003e(F\u003cem\u003e1) or (F\u003c/em\u003e2) bytes\u003c/p\u003e\n\u003cp\u003eExtra Bytes\u003c/p\u003e\n\u003cp\u003e6 bytes\u003c/p\u003e\n\u003cp\u003eField Contents\u003c/p\u003e\n\u003cp\u003edepends on content\u003c/p\u003e\n\u003cp\u003eLegend: The letter ‘F’ stands for ‘Number Of Fields’.\u003c/p\u003e\n\u003cp\u003eThe meaning of the parts is as follows:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThe FIELD START OFFSETS is a list of numbers …\u003c/li\u003e\u003c/ul\u003e"

"\u003cp\u003e这两个名字虽然都叫做索引，但这并不是一种单独的索引类型，而是一种数据存储方式。对于聚簇索引存储来说，行数据和主键B+树存储在一起，辅助键B+树只存储辅助键和主键，主键和非主键B+树几乎是两种类型的树。对于非聚簇索引存储来说，主键B+树在叶子节点存储指向真正数据行的指针，而非主键。\u003c/p\u003e\n\u003cp\u003eInnoDB使用的是聚簇索引，将主键组织到一棵B+树中，而行数据就储存在叶子节点上，若使用”where id = 14″这样的条件查找主键，则按照B+树的检索算法即可查找到对应的叶节点，之后获得行数据。若对Name列进行条件搜索，则需要两个步骤：第一步在辅助索引B+树中检索Name，到达其叶子节点获取对应的主键。第二步使用主键在主索引B+树种再执行一次B+树检索操作，最终到达叶子节点即可获取整行数据。\u003c/p\u003e\n\u003cp\u003eMyISM使用的是非聚簇索引，非聚簇索引的两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于索引树是独立的，通 …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"http://fireflyclub.org/?/article/37\"\u003ehttp://fireflyclub.org/?/article/37\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"http://www.cnblogs.com/yuyue2014/p/4738007.html\"\u003ehttp://www.cnblogs.com/yuyue2014/p/4738007.html\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e注意这篇文章并非死锁的，而是锁等待\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e到information_schema库下面，查看下面这个表：\u003c/p\u003e\n\u003cp\u003einnodb_trx         ## 当前运行的所有事务\u003c/p\u003e\n\u003cp\u003einnodb_locks       ## 当前出现的锁\u003c/p\u003e\n\u003cp\u003einnodb_lock_waits  ## 锁等待的对应关系\u003c/p\u003e\n\u003cp\u003e如果遇到死锁了，怎么解决呢？找到原始的锁ID，然后KILL掉一直持有的那个线程就可以了， 但是众多线程，可怎么找到引起死锁的线程ID呢？ MySQL 发展到现在，已经非常强大了，这个问题很好解决。 直接从数据字典连查找。\u003c/p\u003e\n\u003cp\u003e我们来演示下。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e线程A，我们用来锁定某些记录，假设这个线程一直没提交，或者忘掉提交了。 那么就一直存在，但是数据里面显示的只是SLEEP状态。\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003emysql\u0026gt; set @@autocommit=0;\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eQuery OK, 0 rows affected (0.00 sec)\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003emysql\u0026gt; use test;\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eReading table information for completion oftableandcolumn names\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eYou can turn …\u003c/p\u003e\u003c/li\u003e\u003c/ol\u003e"

"\u003col\u003e\n\u003cli\u003e\n\u003cp\u003emysql\u0026gt; show status like ‘handler_read_%’;\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e+———————–+——-+\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e| Variable_name | Value |\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e+———————–+——-+\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e| Handler_read_first | 1 |\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e| Handler_read_key | 1 |\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e| Handler_read_last | 0 |\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e| Handler_read_next | 0 |\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e| Handler_read_prev | 0 |\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e| Handler_read_rnd | 0 |\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e| Handler_read_rnd_next | 21 |\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e+———————–+——-+\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e7 rows in set (0.01 sec)\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e如上所示，mysql中关于read的计数器，有7个。他们的数值对于系统的状况的了解，对于系统的调优都十分重要。我们应该理解他们的含义。本文是自己的一些理解。\n首先7个计数器，我们应该分为两部分：\n1）对索引读的计数器：前面的5个都是对索引读情况的计数器， …\u003c/p\u003e"

"\u003cp\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/btree.jpg\" alt=\"img\"\u003e\u003c/p\u003e\n\u003cp\u003e其中key 是索引, \u003ccode\u003ed1\u003c/code\u003e、\u003ccode\u003ed2\u003c/code\u003e是索引对应的值，包含更多的信息。\u003c/p\u003e"

"\u003cp\u003e线上用的MySQL版本为5.7.11，线下用的5.6版本，发现将程序上线后，有些地方报这个错误\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e[Err] 1055 – Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column ‘information_schema.PROFILING.SEQ’ which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eONLY_FULL_GROUP_BY：\u003c/strong\u003e\n对于GROUP BY聚合操作，若select中的列没有在group by中出现，那么这句SQL是不合法的。\u003c/p\u003e\n\u003cp\u003e解决办法下my.cnf中添加以下几行\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e[mysqld] …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e\u003cstrong\u003e环境说明：\u003c/strong\u003e\nCentos 6.6 64位\nmysql 使用最新版本5.7.16版本\u003c/p\u003e\n\u003cp\u003e这里安装两个MySQL实例，分别使用3306/3307端口号\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e目录结构：\u003c/strong\u003e\n/data/mysql/mysql3306\n/data/mysql/mysql3306/data\n/data/mysql/mysql3307/log\n/data/mysql/mysql3306/tmp\u003c/p\u003e\n\u003cp\u003e执行命令：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emkdir -p /data/mysql/mysql3306/{data,tmp,log}\nmkdir -p /data/mysql/mysql3307/{data,tmp,log}\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e为了方便我们先配置mysql3306实例，配置成功后，再复制一份到3307即可。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003etar zxvf mysql-5.7.16-linux-glibc2.5-x86_64.tar.gz\ncp -rf mysql-5.7.16-linux-glibc2.5-x86_64/* /data/mysql/mysql3306/\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e权限修改\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003echown -R mysql:mysql /data/mysql/mysql3306\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e配置my.cnf\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ecd …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e\u003ca href=\"https://www.percona.com/doc/percona-xtrabackup/2.4/index.html\"\u003ehttps://www.percona.com/doc/percona-xtrabackup/2.4/index.html\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e下载地址： \u003ca href=\"https://www.percona.com/downloads/XtraBackup/LATEST/\"\u003ehttps://www.percona.com/downloads/XtraBackup/LATEST/\u003c/a\u003e\n一、安装两个必需库\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003esudo yum -y install libdv perl-DBD-MySQL\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e如果libev库在yum源找不到的话，需要在rpmfind.net网站下载自行安装。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ewget ftp://rpmfind.net/linux/dag/redhat/el6/en/x86_64/dag/RPMS/libev-4.15-1.el6.rf.x86_64.rpm\nrpm libev-4.15-1.el6.rf.x86_64.rpm\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e二、安装percona-xtrabackup\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ewget …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2016/11/mysql_ha.jpeg\"\u003e\u003cimg src=\"http://blog.haohtml.com/wp-content/uploads/2016/11/mysql_ha.jpeg\" alt=\"mysql_ha\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eMySQL高可用架构之MHA \u003ca href=\"http://www.cnblogs.com/gomysql/p/3675429.html\"\u003ehttp://www.cnblogs.com/gomysql/p/3675429.html\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e基于PXC的MySQL高可用架构探索 \u003ca href=\"http://www.infoq.com/cn/presentations/mysql-high-availability-architecture-exploration-based-on-pxc\"\u003ehttp://www.infoq.com/cn/presentations/mysql-high-availability-architecture-exploration-based-on-pxc\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e1)InnoDB使用聚集索引，数据记录本身被存于主索引的叶子节点上，这就要求同一个叶子节点内的各条数据记录按主键顺序存放，因此每当一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，如果页面达到装载因子，则开辟一个新的页（节点）。\u003c/p\u003e\n\u003cp\u003e如果表使用自增主键，那么每次插入新的记录时，记录就会顺序添加到当前索引节点后续位置，当一页写满，就会自动开辟一个新的页。这样就就会形成一个紧凑的索引结构，近似顺序填满，由于每次插入时也不需要移动所有数据，因此效率很高，也不会增加很多额外的开销维护索引。\u003c/p\u003e\n\u003cp\u003e如果使用非自增主键，由于每次插入主键的值近乎于随机，因此每次新纪录都要被插到现有索引页的中间某个位置，此时MySQL不得不为了将新纪录插到合适位置而移动数据，甚至目标页面可能已经被写到磁盘而从缓存中清除，这增加了很多额外开销，同时频繁的移动，分页造成了大量的碎片，得到不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE来重建并优化填充页面。\u003c/p\u003e\n\u003cp\u003e2)由于MySQL从磁盘读取数据时一块一块来读取的，同时，根据局部性原理，MySQL引擎会选择预读一部分和你当前读数据所在内存相邻的数据块，这个 …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"http://imysql.cn/2015/04/12/mysql-optimization-case-howto-resolve-slave-delay.shtml\"\u003ehttp://imysql.cn/2015/04/12/mysql-optimization-case-howto-resolve-slave-delay.shtml\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"https://www.qcloud.com/community/article/203\"\u003ehttps://www.qcloud.com/community/article/203\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e1、  如一个表有10个int类型的字段，那么每行数据大小为\u003c/p\u003e\n\u003cp\u003e4(每个int类型占用4字节byte） * 10 = 40Bytes\u003c/p\u003e\n\u003cp\u003e[\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/mysql_int_datatype.png\" alt=\"mysql_int_datatype\"\u003e][1]\u003c/p\u003e\n\u003cp\u003e2、 如一个表有10个varchar(20)的字段，编码为utf8，那每行占用大小为\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e3(每个汉字占用3字节) * 20 * 10 = 600Bytes\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e如果是英文字符的话，则为\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e1（1个字符占用1个字节) * 20  * 10 = 200Bytes\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e[\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/mysql_varchar_datatype.png\" alt=\"mysql_varchar_datatype\"\u003e][2]\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e则以上两种情况 ，每行的数据均\u0026lt;8K (1024byte * 8) ,符合以下规则( 1024byte = 1KB)\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e[\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/mysql.png\" alt=\"mysql\"\u003e]\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"http://imysql.cn/2014/10/10/tpcc-mysql-full-user-manual.shtml\"\u003ehttp://imysql.cn/2014/10/10/tpcc-mysql-full-user-manual.shtml\u003c/a\u003e \u003ca href=\"http://imysql.com/tag/%E5%8E%8B%E6%B5%8B\"\u003ehttp://imysql.com/tag/压测\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e[\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/mysq_index.png\" alt=\"mysq_index\"\u003e][1]\u003c/p\u003e\n\u003cp\u003e下面分析下索引和锁的关系。\n1）delete from msg where id=2；\u003c/p\u003e\n\u003cp\u003e由于id是主键，因此直接锁住整行记录即可。\n\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/2f67547e0caa0d1ea9bc7cb53966eedf70d49db3.png\" alt=\"\"\u003e                                                                                图5\n2)delete from msg where token=’ cvs’;\u003c/p\u003e\n\u003cp\u003e由于token是二级索引，因此首先锁住二级索引（两行），接着会锁住相应主键所对应的记录；\n\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/e0ac34fd99404ccdee4ab1ec4889f47754ffcd82.png\" alt=\"\"\u003e                                                                        图6\n3)delete from msg where message=订单号是多少’；\u003c/p\u003e\n\u003cp\u003emessage没有索引，所以走的是全表扫描过滤。这时表上的各个记录都将添加上X锁。\n\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/aa9a94c735ec35cfe92cd5eca1015893aad8de58.png\" alt=\"\"\u003e                                                                         图7\u003c/p\u003e\n\u003cp\u003e强烈推荐阅读： …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003ekey_buffer_size\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e设置这个变量给键缓冲区(或者说键缓存)分配指定大小的空间。但是操作系统只有在实际用到这些空间的时候才会进行分配。例如，将键缓冲区大小设置为1GB，并不意味着服务器就会真正地给它分配1GB空间。\u003c/p\u003e\n\u003cp\u003e对一个已有的缓存设置非零值将会冲洗缓存，从技术上来说，这是一个在线操作，但是它会阻止所有访问该缓存的动作，直到缓存冲洗完成。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003etable_cache_size\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e设置这个变量是不会立即生效，要等到下一个线程打开表的时候才会生效。当它生效的时候，MYSQL会检查变量的值。如果值大于缓存中表的数量，线程就可以把新打开的表插入到缓存中。如果值小于缓存中表的数量，MySQL就会从缓存中删除掉没有使用的表。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ethread_cache_size\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e设置这个变量不会立即生效，生效被延时到了下一次线程关闭的时候。在那时，MySQL检查缓存中是否有空间存储线程。如果是，它会把线程缓存起来，供另外一个连接使用。如果不是，它会直接结束掉线程。在这种情况下，缓存中线程的数量，以及线程缓存使用的内存数量不会立即就下降。只有当新连接为了使用线程把它从缓存中移走的时候才会看到下降。（MySQL只有 …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"https://yq.aliyun.com/articles/59256\"\u003ehttps://yq.aliyun.com/articles/59256\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e为了给高并发情况下的mysql进行更好的优化，有必要了解一下mysql查询更新时的锁表机制。\n**一、概述\n** MySQL有三种锁的级别：页级、表级、行级。\nMyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。\nMySQL这3种锁的特性可大致归纳如下：\n表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。\n行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。\n页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。\u003c/p\u003e\n\u003cp\u003e从上述特点可见，很难笼统地说哪种锁更好，只能就具体应用的特点来说哪种锁更合适！仅从锁的角度来说：表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用；而行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并 …\u003c/p\u003e"

"\u003ch2 id=\"导读\"\u003e导读\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e在MySQL里，聚集索引和非聚集索引分别是什么意思，有什么区别？\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e在MySQL中，InnoDB引擎表是（聚集）索引组织表（clustered index organize table），而MyISAM引擎表则是堆组织表（heap organize table）。\u003c/p\u003e\n\u003cp\u003e也有人把聚集索引称为聚簇索引。\u003c/p\u003e\n\u003cp\u003e当然了，聚集索引的概念不是MySQL里特有的，其他数据库系统也同样有。\u003c/p\u003e\n\u003cp\u003e简言之，\u003cstrong\u003e聚集索引是一种索引组织形式，索引的键值逻辑顺序决定了表数据行的物理存储顺序\u003c/strong\u003e，而非聚集索引则就是普通索引了，仅仅只是对数据列创建相应的索引，不影响整个表的物理存储顺序。\u003c/p\u003e\n\u003cp\u003e我们先来看看两种存储形式的不同之处：\u003c/p\u003e\n\u003cp\u003e简单说，IOT表里数据物理存储顺序和主键索引的顺序一致，所以\u003cstrong\u003e如果新增数据是离散的，会导致数据块趋于离散\u003c/strong\u003e，而不是趋于顺序。而HOT表数据写入的顺序是按写入时间顺序存储的。\nIOT表相比HOT表的\u003cstrong\u003e优势\u003c/strong\u003e是：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e范围查询效率更高；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e数据频繁更新（聚集索引本身不更新）时，更不容易产生碎片；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e特别适合有一小部分热点数据频繁读写的场景；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e通过主键访问数据时快速可达；\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIOT表的\u003cstrong\u003e不足\u003c/strong\u003e则有：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e数据变化如果 …\u003c/li\u003e\u003c/ul\u003e"

"\u003cp\u003e其实对于非专业的数据库操作人员来讲，例如软件开发人员，在很大程度上都搞不清楚数据库索引的一些基本知识，有些是知其一不知其二，或者是知其然不知其所以然。造成这种情况的主要原因我觉的是行业原因，有很多公司都有自己的DBA团队，他们会帮助你优化SQL，开发人员即使不懂优化问题也不大，所以开发人员对这方面也就不会下太多功夫去了解SQL优化，但如果公司没有这样的DBA呢，就只能靠程序员自己了。 最近突然想起前一阵和一朋友的聊天，当时他问我的问题是一个非常普通的问题：说说SQL聚集索引和非聚集索引的区别。\u003c/p\u003e\n\u003cp\u003e大家可能认为这个问题难度不大，认为太熟悉了，也许不会感兴趣，但你真能说清楚吗？其实要想说明白这两者的差别也不是三两句就说的清的，那天我也是觉的这问题太泛了，就随便说了其中的两个区别：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e聚集索引一个表只能有一个，而非聚集索引一个表可以存在多个，这个跟没问题没差别，一般人都知道。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e聚集索引存储记录是物理上连续存在，而非聚集索引是逻辑上的连续，物理存储并不连续，这个大家也都知道。\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e上面的两点从大的方面讲都是讲的通的，后面我们继续探讨，举一个实际点的例子，一个学生表student，里面是学生 …\u003c/p\u003e"

"\u003cp\u003eMySQL聚簇索引\u0026amp;聚集索引\u0026amp;索引组织表\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://www.cnblogs.com/hustcat/archive/2009/10/28/1591648.html\"\u003ehttp://www.cnblogs.com/hustcat/archive/2009/10/28/1591648.html\u003c/a\u003e\u003c/p\u003e\n\u003ch1 id=\"聚簇索引和聚集索引clustered-index\"\u003e聚簇索引和聚集索引(Clustered Index)\u003c/h1\u003e\n\u003cp\u003e说起索引，不能不说B+树。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e引用： \u003ca href=\"http://blog.codinglabs.org/articles/theory-of-mysql-index.html\"\u003ehttp://blog.codinglabs.org/articles/theory-of-mysql-index.html\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eMySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。提取句子主干，就可以得到索引的本质：索引是数据结构。\u003c/p\u003e\n\u003cp\u003e我们知道，数据库查询是数据库的最主要功能之一。我们都希望查询数据的速度能尽可能的快，因此数据库系统的设计者会从查询算法的角度进行优化。\u003cem\u003e\u003cstrong\u003e最基本的查询算法当然是顺序查找（linear search）\u003c/strong\u003e\u003c/em\u003e，这种复杂度为O(n)的算法在数据量很大时显然是糟糕的，好在计算机科学的发展提供了很多更优秀的查找算法，例如\u003cstrong\u003e二分查找（binary search），\u003c/strong\u003e\u003cem\u003e\u003cstrong\u003e二叉树查找（binary tree search）\u003c/strong\u003e\u003cem\u003e等。如果稍微分析一下会发现，每种查找算法都只能应用于特定的数据结 …\u003c/em\u003e\u003c/em\u003e\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cp\u003e要说表空间，Mysql的表空间管理远远说不上完善。换句话说，事实上Mysql根本没有真正意义上的表空间管理。Mysql的Innodb包含两种表空间文件模式，默认的共享表空间和每个表分离的独立表空间。只要在my.cnf里面增加innodb_file_per_table=1就可以从共享表空间切换到独立表空间。当然对于已经存在的表，则需要执行alter table MY_TABLE engine=innodb命令迁移数据。\u003c/p\u003e\n\u003ch1 id=\"共享表空间方式\"\u003e\u003cstrong\u003e共享表空间方式\u003c/strong\u003e\u003c/h1\u003e\n\u003cp\u003e由于是默认的方式，就暂且理解为Mysql官方推荐的方式。相对而言所有的数据都在一个（或几个）文件中，比较利于管理，而且在操作的时候只需要open这一个（或几个）文件即可，相对来说代价很低。\u003c/p\u003e\n\u003cp\u003e但问题是在数据达到以G为单位来计算的时候优劣逆转。一个大小惊人的文件很不利于管理，而且对于一个如此巨大的文件来说，读写它需要耗费的资源一样巨大。更加令人费解的是，MySQL竟然将索引和数据保存于同一个文件中，索引和数据之间尚存在资源争用，不利于性能的提升。你当然可以通过innodb_data_file_path的配置规划多个表空间文件，但MySQL的逻辑是“用满后增 …\u003c/p\u003e"

"\u003cp\u003e本次，我们通过对比，明明白白的知道索引、提交频率对InnoDB表写入速度的影响，了解有哪些需要注意的。\u003c/p\u003e\n\u003cp\u003e先直接说几个结论吧：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e1、关于索引对写入速度的影响：\na、如果有自增列做主键，相对完全没索引的情况，写入速度约提升 3.11%；\nb、如果有自增列做主键，并且二级索引，相对完全没索引的情况，写入速度约降低 27.37%；\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e因此，\u003cstrong\u003eInnoDB表最好总是有一个自增列做主键\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e2、关于提交频率对写入速度的影响（以表中只有自增列做主键的场景，一次写入数据30万行数据为例）：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003ea、等待全部数据写入完成后，最后再执行commit提交的效率最高；\nb、每10万行提交一次，相对一次性提交，约慢了1.17%；\nc、每1万行提交一次，相对一次性提交，约慢了3.01%；\nd、每1千行提交一次，相对一次性提交，约慢了23.38%；\ne、每100行提交一次，相对一次性提交，约慢了24.44%；\nf、每10行提交一次，相对一次性提交，约慢了92.78%；\ng、每行提交一次，相对一次性提交，约慢了546.78%，也就是慢了5倍；\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e因此，\u003cstrong\u003e最好是等待所有事务结束后再批量提交，而不是每执行完一个SQL就提交一次\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e曾经 …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003eMySQL在以下几种情况会创建临时表：\u003c/strong\u003e\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e1、UNION查询；\n2、用到TEMPTABLE算法或者是UNION查询中的视图；\n3、ORDER BY和GROUP BY的子句不一样时；\n4、表连接中，ORDER BY的列不是驱动表中的；\n5、DISTINCT查询并且加上ORDER BY时；\n6、SQL中用到SQL_SMALL_RESULT选项时；\n7、FROM中的子查询；\n8、子查询或者semi-join时创建的表；\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eEXPLAIN 查看执行计划结果的 Extra 列中，如果包含 ** \u003ca href=\"http://imysql.com/2015/06/14/mysql-faq-what-important-information-in-explain.shtml\"\u003eUsing Temporary\u003c/a\u003e** 就表示会用到临时表。\u003c/p\u003e\n\u003cp\u003e当然了，如果临时表中需要存储的数据量超过了上限（ \u003ca href=\"https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_tmp_table_size\"\u003etmp-table-size\u003c/a\u003e 或 \u003ca href=\"https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_max_heap_table_size\"\u003emax-heap-table-size\u003c/a\u003e 中取其大者），这时候就需要生成基于磁盘的临时表了。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e在以下几种情况下，会创建磁盘临时表：\u003c/strong\u003e\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e1、数据表中包含BLOB/TEXT列；\n2、在 GROUP BY 或者 DSTINCT 的列中有超过 512字符 的字符类型列（或者超过 512字节的 二进制类型列，在5.6.15之前只管是否超过512字节）；\n3、 …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e我们先了解下InnoDB引擎表的一些关键特征：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003eInnoDB引擎表是基于B+树的索引组织表(IOT)；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e每个表都需要有一个聚集索引(clustered index)；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e所有的行记录都存储在B+树的叶子节点(leaf pages of the tree)；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e基于聚集索引的增、删、改、查的效率相对是最高的；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择其作为聚集索引；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e综上总结，如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话，这时候存取效率是最高的，也就是下面这几种情况的存取效率最高：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e使用自增列(INT/BIGINT类型)做主键，这时候写入顺序是自增的，和B+数叶子节点分裂顺序一致；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e该表不指定自增列做主键，同时也没有可 …\u003c/p\u003e\u003c/li\u003e\u003c/ul\u003e"

"\u003cp\u003e很多时候由于异常或程序错误会导致个别进程占用大量系统资源，需要结束这些进程，通常可以使用以下命令Kill进程:\u003c/p\u003e\n\u003cp\u003emysql中kill掉所有锁表的进程\u003c/p\u003e\n\u003cp\u003e3点钟刚睡下, 4点多, 同事打电话告诉我用户数据库挂掉了. 我起床看一下进程列表.\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql\u0026gt;show process list;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e出来哗啦啦好几屏幕的, 没有一千也有几百条, 查询语句把表锁住了, 赶紧找出第一个Locked的thread_id, 在mysql的shell里面执行.\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql\u0026gt;kill thread_id;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003ekill掉第一个锁表的进程, 依然没有改善. 既然不改善, 咱们就想办法将所有锁表的进程kill掉吧, 简单的脚本如下.\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e#!/bin/bash\nmysql -u root -e \u0026#34;show processlist\u0026#34; | grep -i \u0026#34;Locked\u0026#34; \u0026gt;\u0026gt; locked_log.txt for line in `cat locked_log.txt | awk \u0026#39;{print $1}\u0026#39;`\ndo\necho \u0026#34;kill …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003eshell脚本检测和检查mysql数据库是否存在坏表\u003c/p\u003e\n\u003cp\u003e此脚本的主要用途是检测mysql服务器上所有的数据库或者单独数据库中的坏表，适用于RHEL/Centos系列\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2015/07/check_mysql.png\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/check_mysql.png\" alt=\"check_mysql\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e#!/bin/bash\n#此脚本的主要用途是检测mysql服务器上所有的db或者单独db中的坏表\n#变量说明 pass mysql账户口令 name mysql账号名称 data_path mysql目录路径 directory_list 目录列表 file_list文件列表 db_name 数据库名称 repair_count单库中待修复的表总数\n#变量说明 repair_count_all所有库中待修复的表总数 mysql_version mysql版本 _file_name 数据表名称\n\necho -e \u0026#34;此脚本的主要用途是检测mysql服务器上所有的数据库或者单独数据库中的坏表\\n\\n\u0026#34;\npass=123456\nname=root\n\nread -p \u0026#34;输入mysql存储路径: \u0026#34; choose\ndata_path=$choose\nunset choose\n\nread -p …\u003c/code\u003e\u003c/pre\u003e"

"\u003ch2 id=\"112-数值类型\"\u003e11.2. 数值类型\u003c/h2\u003e\n\u003cp\u003eMySQL支持所有标准SQL数值数据类型。这些类型包括严格数值数据类型(INTEGER、SMALLINT、DECIMAL和NUMERIC)，以及近似数值数据类型(FLOAT、REAL和DOUBLE PRECISION)。关键字INT是INTEGER的同义词，关键字DEC是DECIMAL的同义词。\u003c/p\u003e\n\u003cp\u003eBIT数据类型保存位字段值，并且支持MyISAM、MEMORY、InnoDB和BDB表。\u003c/p\u003e\n\u003cp\u003e作为SQL标准的扩展，MySQL也支持整数类型TINYINT、MEDIUMINT和BIGINT。下面的表显示了需要的每个整数类型的存储和范围。\u003c/p\u003e\n\u003ctable\u003e\n \u003cthead\u003e\n \u003ctr\u003e\n \u003cth\u003e\u003cstrong\u003e类型\u003c/strong\u003e\u003c/th\u003e\n \u003cth\u003e\u003cstrong\u003e字节\u003c/strong\u003e\u003c/th\u003e\n \u003cth\u003e\u003cstrong\u003e最小值\u003c/strong\u003e\u003c/th\u003e\n \u003cth\u003e\u003cstrong\u003e最大值\u003c/strong\u003e\u003c/th\u003e\n \u003c/tr\u003e\n \u003c/thead\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd\u003e\u003c/td\u003e\n \u003ctd\u003e\u003c/td\u003e\n \u003ctd\u003e\u003cstrong\u003e(带符号的/无符号的)\u003c/strong\u003e\u003c/td\u003e\n \u003ctd\u003e\u003cstrong\u003e(带符号的/无符号的)\u003c/strong\u003e\u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd\u003eTINYINT\u003c/td\u003e\n \u003ctd\u003e1\u003c/td\u003e\n \u003ctd\u003e-128\u003c/td\u003e\n \u003ctd\u003e127 …\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e"

"\u003ch2 id=\"一获取锁等待情况\"\u003e一、获取锁等待情况\u003c/h2\u003e\n\u003cp\u003e可以通过检查table_locks_waited和table_locks_immediate状态变量来分析系统上的表锁定争夺：\nmysql\u0026gt; show status like ‘Table%’;\n+—————————-+———-+\n| Variable_name       | Value |\n+—————————-+———-+\n| Table_locks_immediate   | 105       |\n| Table_locks_waited  | 3     |\n+—————————-+———-+\n2 rows in set (0.00 sec)\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTable_locks_immediate\u003c/strong\u003e 表示立即释放MySQL表锁数，\n\u003cstrong\u003eTable_locks_waited\u003c/strong\u003e 表示需要等待的MySQL表锁数\u003c/p\u003e\n\u003cp\u003e如果Table_locks_waited的值比较高，则说明存在着较严重的表级锁争用情况。这时，需要我们对应用做进一步的检查，来确定问题所在。\u003c/p\u003e\n\u003cp\u003e可以通过检查Innodb_row_lock状态变量来分析系统上的行锁的争夺情况：\nmysql\u0026gt; show status …\u003c/p\u003e"

"\u003cp\u003e作/译者：叶金荣（imysql#imysql.com\u0026gt;），来源： \u003ca href=\"http://imysql.com/\"\u003ehttp://imysql.com\u003c/a\u003e，欢迎转载。\u003c/p\u003e\n\u003cp\u003e起因：在innodb表上做count(*)统计实在是太慢了，因此想办法看能不能再快点。\u003c/p\u003e\n\u003cp\u003e现象：先来看几个测试案例，如下\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一、 sbtest 表上的测试\u003c/strong\u003e\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eshow create table sbtest\\G\n*************************** 1. row ***************************\nTable: sbtest\nCreate Table: CREATE TABLE `sbtest` (\n`aid` bigint(20) unsigned NOT NULL auto_increment,\n`id` int(10) unsigned NOT NULL default \u0026#39;0\u0026#39;,\n`k` int(10) unsigned NOT NULL default \u0026#39;0\u0026#39;,\n`c` char(120) NOT NULL default \u0026#39;\u0026#39;,\n`pad` char(60) NOT NULL …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e以下摘自mysql5手册\u003c/p\u003e\n\u003cp\u003e您可以使用CHANGE _old_col_name__column_definition_子句对列进行重命名。重命名时，需给定旧的和新的列名称和列当前的类型。例如：要把一个INTEGER列的名称从a变更到b，您需要如下操作：\u003c/p\u003e\n\u003cp\u003e·                mysql\u0026gt; \u003cstrong\u003eALTER TABLE t1 CHANGE a b INTEGER;\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e如果您想要更改列的类型而不是名称， CHANGE语法仍然要求旧的和新的列名称，即使旧的和新的列名称是一样的。例如：\u003c/p\u003e\n\u003cp\u003emysql\u0026gt; \u003cstrong\u003eALTER TABLE t1 CHANGE b b BIGINT NOT NULL;\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e您也可以使用MODIFY来改变列的类型，此时不需要重命名：\u003c/p\u003e\n\u003cp\u003emysql\u0026gt; \u003cstrong\u003eALTER TABLE t1 MODIFY b BIGINT NOT NULL;\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003emysql alter 语句用法,添加、修改、删除字段等\u003c/p\u003e\n\u003cp\u003e//主键549830479\u003c/p\u003e\n\u003cp\u003ealter table tabelname add new_field_id int(5) unsigned default 0 not null …\u003c/p\u003e"

"\u003cp\u003e在主从复制中，难免会遇到一些sql语句错误的问题。这个时候我们需要手动来重新设置中继日志的起始点了，有些麻烦。今天在看“2012华东架构师大会”视频的时候，发现淘宝丁奇的ppt里有这个参数,看名字就知道是让从库跳过一些错误了。以前没有注意过这个参数，这里了解一下这个参数的用法。\u003c/p\u003e\n\u003cp\u003e—————————————-\u003c/p\u003e\n\u003cp\u003e环境说明：\u003c/p\u003e\n\u003cp\u003emysql\u0026gt;show  slave stsatus\\G;\u003c/p\u003e\n\u003cp\u003e报错信息如下：\u003c/p\u003e\n\u003cp\u003e……\u003c/p\u003e\n\u003cp\u003eLast_Errno: 1062\u003c/p\u003e\n\u003cp\u003eLast_Error: Error ‘Duplicate entry ‘1’ for key ‘PRIMARY” on query…….\u003c/p\u003e\n\u003cp\u003e……\u003c/p\u003e\n\u003cp\u003e1062的错误是指一些主键重复的错误，在my.cnf用slave-skip-erros　可以跳过去。这样就避免了由于sql出错导致的从复制失效。\u003c/p\u003e\n\u003cp\u003e—————————————-\u003c/p\u003e\n\u003cp\u003eError_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;\u003c/p\u003e\n\u003cp\u003e造成1032错误的根本原因是主从数据库数据不一致,导致同步操作在从库上无法执行.解决办法同上\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e在slave的my.cnf …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e话说有这么一个表：\u003c/p\u003e\n\u003cp\u003eCREATE TABLE \u003ccode\u003euser_group\u003c/code\u003e (\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eid\u003c/code\u003e int(11) NOT NULL auto_increment,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003euid\u003c/code\u003e int(11) NOT NULL,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003egroup_id\u003c/code\u003e int(11) NOT NULL,\u003c/p\u003e\n\u003cp\u003ePRIMARY KEY  (\u003ccode\u003eid\u003c/code\u003e),\u003c/p\u003e\n\u003cp\u003eKEY \u003ccode\u003euid\u003c/code\u003e (\u003ccode\u003euid\u003c/code\u003e),\u003c/p\u003e\n\u003cp\u003eKEY \u003ccode\u003egroup_id\u003c/code\u003e (\u003ccode\u003egroup_id\u003c/code\u003e),\u003c/p\u003e\n\u003cp\u003e) ENGINE=InnoDB AUTO_INCREMENT=750366 DEFAULT CHARSET=utf8\u003c/p\u003e\n\u003cp\u003e看AUTO_INCREMENT就知道数据并不多，75万条。然后是一条简单的查询：\u003c/p\u003e\n\u003cp\u003e　　SELECT SQL_NO_CACHE uid FROM user_group WHERE group_id = 245;\u003c/p\u003e\n\u003cp\u003e很简单对不对?怪异的地方在于：\u003c/p\u003e\n\u003cp\u003e如果换成MyISAM做存储引擎的时候，查询耗时只需要0.01s，用InnoDB却会是0.15s左右。\u003c/p\u003e\n\u003cp\u003e如果只是就这么点差距其实不是什么大不了的事，但是真实的业务需求比这个复杂，造成的差距也很大：MyISAM只需要0.12s，InnoDB则需要2.2s.，最终定位到问题症结是在这 …\u003c/p\u003e"

"\u003cp\u003e【TechTarget中国原创】如果您接手了一个 \u003ca href=\"http://www.searchdatabase.com.cn/showcontent_66381.htm\"\u003eMySQL\u003c/a\u003e 生产系统，但不确定它是否运行了MySQL备份策略，这时需要做哪些保障措施呢？在实施备份策略之前，一定要明确数据规模和存储引擎使用等先决条件。这会对系统在备份过程中的可用性产生直接影响。\u003c/p\u003e\n\u003cp\u003e在本文中，我们将介绍用于确定最小备份功能所需要的方法，其中包括：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e确定数据库规模\u003c/li\u003e\n\u003cli\u003e确定存储引擎使用率\u003c/li\u003e\n\u003cli\u003e锁定和停机时间影响\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eMySQL备份方法\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e备份MySQL环境的策略有很多，这些策略与MySQL拓扑的服务器数量相关，有许多开源和商业工具可以执行备份操作。\u003c/p\u003e\n\u003cp\u003e假设目前您有一个单服务器环境，希望创建一个统一备份，那么您现在可以在所有MySQL环境中采用两种备份方法。第一种方法是停止MySQL实例，然后对整个文件系统执行冷备份。这样会让系统在特定时间段变成不可用状态，而且您必须确保复制了所有信息，其中包括MySQL数据、事务与二进制日志文件（如果有的话）和MySQL的当前配置。\u003c/p\u003e\n\u003cp\u003e第二种方法是使用MySQL标准安装所包含的客户端工具。使用mysqldump命令，可以在不停止MySQL实例的前提下创建一个统一的MySQL备份。然而，在运 …\u003c/p\u003e"

"\u003cp\u003e今天丁原问我mysql执行计划中的key_len是怎么计算得到的，当时还没有注意，在高性能的那本书讲到过这个值的计算，但是自己看执行计划的时候一直都没有太在意这个值，更不用说深讨这个值的计算了：\u003c/p\u003e\n\u003cp\u003eken_len表示索引使用的字节数，根据这个值，就可以判断索引使用情况，特别是在组合索引的时候，判断所有的索引字段都被查询用到。\u003c/p\u003e\n\u003cp\u003e在查看官方文档的时候，也没有发现详细的key_len的计算介绍，后来做了一些测试，在咨询了丁奇关于变长数据类型的值计算的时候，突然想到innodb 行的格式，在这里的计算中有点类似，总结一下需要考虑到以下一些情况：(1).索引字段的附加信息：可以分为\u003cstrong\u003e变长\u003c/strong\u003e和\u003cstrong\u003e定长\u003c/strong\u003e数据类型讨论\n当索引字段为定长数据类型，比如char，int，datetime，需要有是否为空的标记，这个标记需要占用\u003cstrong\u003e1\u003c/strong\u003e个字节；\n对于变长数据类型，比如：varchar，除了是否为空的标记外，还需要有长度信息，需要占用\u003cstrong\u003e2\u003c/strong\u003e个字节；\u003c/p\u003e\n\u003cp\u003e(备注：当字段定义为非空的时候，是否为空的标记将不占用字节)\u003c/p\u003e\n\u003cp\u003e(2).同时还需要考虑表所使用的字符集，不同的字符集，gbk编码的为一个字符2个字节，utf8编码的一个字符3个字节;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e先 …\u003c/strong\u003e\u003c/p\u003e"

"\u003cp\u003e由于MySQL数据库是基于行（Row）存储的数据库，而数据库操作 IO 的时候是以 page（block）的方式，也就是说，如果我们每条记录所占用的空间量减小，就会使每个page中可存放的数据行数增大，那么每次 IO 可访问的行数也就增多了。反过来说，处理相同行数的数据，需要访问的 page 就会减少，也就是 IO 操作次数降低，直接提升性能。此外，由于我们的内存是有限的，增加每个page中存放的数据行数，就等于增加每个内存块的缓存数据量，同时还会提升内存换中数据命中的几率，也就是缓存命中率。\u003c/p\u003e\n\u003cp\u003e**　　数据类型选择**\u003c/p\u003e\n\u003cp\u003e数据库操作中最为耗时的操作就是 IO 处理，大部分数据库操作 90% 以上的时间都花在了 IO 读写上面。所以尽可能减少 IO 读写量，可以在很大程度上提高数据库操作的性能。\u003c/p\u003e\n\u003cp\u003e我们无法改变数据库中需要存储的数据，但是我们可以在这些数据的存储方式方面花一些心思。下面的这些关于字段类型的优化建议主要适用于记录条数较多，数据量较大的场景，因为精细化的数据类型设置可能带来维护成本的提高，过度优化也可能会带来其他的问题：\u003c/p\u003e\n\u003cp\u003e1、数字类型：非万不得已不要使用DOUBLE，不仅仅只是存 …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e摘要\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e本文以MySQL数据库为研究对象，讨论与数据库索引相关的一些话题。特别需要说明的是，MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引，至于哈希索引和全文索引本文暂不讨论。\u003c/p\u003e\n\u003cp\u003e文章主要内容分为三个部分。\u003c/p\u003e\n\u003cp\u003e第一部分主要从数据结构及算法理论层面讨论MySQL数据库索引的数理基础。\u003c/p\u003e\n\u003cp\u003e第二部分结合MySQL数据库中MyISAM和InnoDB数据存储引擎中索引的架构实现讨论\u003cstrong\u003e聚集索引\u003c/strong\u003e、\u003cstrong\u003e非聚集索引\u003c/strong\u003e及\u003cstrong\u003e覆盖索引\u003c/strong\u003e等话题。\u003c/p\u003e\n\u003cp\u003e第三部分根据上面的理论基础，讨论MySQL中高性能使用索引的策略。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e数据结构及算法基础\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e索引的本质\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eMySQL官方对索引的定义为：**索引（Index）是帮助MySQL高效获取数据的数据结构。**提取句子主干，就可以得到索引的本质：索引是数据结构。\u003c/p\u003e\n\u003cp\u003e我们知道，数据库查询是数据库的最主要功能之一。我们都希望查询数据的速度能尽可能的快，因此数据库系统的设计者会从查询算法的角度进行优化。 …\u003c/p\u003e"

"\u003ch1 id=\"mysql开发规范\"\u003eMySQL开发规范\u003c/h1\u003e\n\u003cp\u003e说明，此规范为内部制定的一个给开发人员如何使用MySQL的规范，由Team共同讨论制定，还在不断的完善中，有一些建议或者规定不一定十分合理，后续可能会修改。另外，MySQL版本不断进化，也会导致有一些条款失效，请大家根据自身的情况谨慎参考。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一、\u003c/strong\u003e \u003cstrong\u003e表设计\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e库名、表名、字段名必须使用小写字母，“_”分割。 \u003ca href=\"#MySQL-1-1\"\u003e【FAQ】\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e库名、表名、字段名必须不超过12个字符。 \u003ca href=\"#MySQL-1-2\"\u003e【FAQ】\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e库名、表名、字段名见名知意,建议使用名词而不是动词。 \u003ca href=\"#MySQL-1-3\"\u003e【FAQ】\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e建议使用InnoDB存储引擎。 \u003ca href=\"#MySQL-1-4\"\u003e【FAQ】\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e存储精确浮点数必须使用DECIMAL替代FLOAT和DOUBLE。 \u003ca href=\"#MySQL-1-5\"\u003e【FAQ】\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e建议使用UNSIGNED存储非负数值。 \u003ca href=\"#MySQL-1-6\"\u003e【FAQ】\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e建议使用INT UNSIGNED存储IPV4。 \u003ca href=\"#MySQL-1-7\"\u003e【FAQ】\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e整形定义中不添加长度，比如使用INT，而不是INT(4)。 \u003ca href=\"#MySQL-1-8\"\u003e【FAQ】\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e使用短数据类型，比如取值范围为0-80时，使用TINYINT UNSIGNED。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e不建议使用ENUM类型，使用TINYINT来代替。 \u003ca href=\"#MySQL-1-10\"\u003e【FAQ】\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e尽可能不使用TEXT、BLOB类型。 …\u003c/p\u003e\u003c/li\u003e\u003c/ol\u003e"

"\u003cp\u003e在MySQL服务器出现短暂(5~30秒)的性能波动的时候，一般的性能监控工具都很难抓住故障现场，也就很难收集对应较细粒度的诊断信息。另外，如果这种波动出现的频率很低，例如几天才一次，我们也很难人为的抓住现场，收集数据。这正是pt-stalk所解决的问题。\u003c/p\u003e\n\u003cp\u003ept-stalk是 \u003ca href=\"http://www.percona.com/software/percona-toolkit/\"\u003ePercona-Toolkit\u003c/a\u003e 的一部分(其前身是\u003ca href=\"http://code.google.com/p/aspersa/\"\u003eAspersa\u003c/a\u003e的一部分)。安装Percona-Toolkit后，可以通过man pt-stalk了解如何使用该工具，本文的介绍是man pt-stalk的一个子集，强烈建议直接阅读man pt-stalk。额外的，本文将提供pt-stalk示例命令可供参考。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1. 使用pt-stalk\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003ept-stalk –collect-tcpdump –function status \\\u003c/p\u003e\n\u003cp\u003e–variable Threads_connected –threshold 2500 \\\u003c/p\u003e\n\u003cp\u003e–daemonize — –user=root –password=YOURPASSWORD\u003c/p\u003e\n\u003cp\u003e上面的命令表示，让pt-stalk后台运行(–daemonize)，并监视SHOW GLOBAL STATUS …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e导读：\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e         淘宝丁奇分享的PPT：MySQL数据库的IO操作，详细分享了四块的内容，并且告诉大家如何调整MySQL数据库IO操作相关的参数，给出了详细的选择策略，现替其整理成文章分享与此。\u003c/p\u003e\n\u003cp\u003ePPT内容提纲：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1.MySQL的文件及简介\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2.数据访问流程\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3.文件访问模式\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e4.影响io行为的一些参数和选择策略\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1.MySQL的文件及简介\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://www.mysqlops.com/wp-content/uploads/2012/05/mysqlops-io-1.png\"\u003e\u003cimg src=\"http://www.mysqlops.com/wp-content/uploads/2012/05/mysqlops-io-1.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2.数据访问流程\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e一个简单的查询 select * from t where id\u0026gt;=(  select id from t where k1=100 limit 100000,1) limit 2;\u003c/p\u003e\n\u003cp\u003e表结构：\u003c/p\u003e\n\u003cp\u003eCREATE TABLE \u003ccode\u003et\u003c/code\u003e (\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eid\u003c/code\u003e int(11) NOT NULL,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ek1\u003c/code\u003e int(11) DEFAULT NULL,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003edata\u003c/code\u003e char(100) DEFAULT NULL,\u003c/p\u003e\n\u003cp\u003ePRIMARY KEY (\u003ccode\u003eid\u003c/code\u003e),\u003c/p\u003e\n\u003cp\u003eKEY \u003ccode\u003ek1\u003c/code\u003e (\u003ccode\u003ek1\u003c/code\u003e)\u003c/p\u003e\n\u003cp\u003e) ENGINE=InnoDB DEFAULT CHARSET=gbk;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3.数据访问流程\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://www.mysqlops.com/wp-content/uploads/2012/05/mysqlops-io-2.png\"\u003e\u003cimg src=\"http://www.mysqlops.com/wp-content/uploads/2012/05/mysqlops-io-2.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e4.数据访问流程\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e一个简单的更新   insert into t values(1, …\u003c/p\u003e"

"\u003cp\u003e(译者注：作者借这个题目反讽另一篇同名的文章)\u003c/p\u003e\n\u003cp\u003eJaslabs的Justin Silverton列出了\u003ca href=\"http://www.whenpenguinsattack.com/2007/04/09/10-tips-for-optimizing-mysql-queries/?2b4ffb70\"\u003e十条有关优化MySQL查询的语句\u003c/a\u003e，我不得不对此发表言论，因为这个清单非常非常糟糕。另外一个\u003ca href=\"http://immike.net/blog/2007/04/09/how-not-to-optimize-a-mysql-query/\"\u003eMike\u003c/a\u003e也同样意识到了。所以在这个博客中，我要做两件事情，第一，指出为什么这个清单很糟糕，第二，列出我的清单，希望我的比较好些。继续看吧，无畏的读者们！\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e为什么那个清单很糟糕\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1.他的力气没使对地方\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e我们要遵循的一个准则就是如果你要优化代码时，应该先找出瓶颈在哪。然而Silverton先生的力气没有用对地方。我认为60%的优化是基于清楚理解SQL和数据库基础的。你需要知道join和子查询的区别，列索引，以及如何将数据规范化等等。另外的35%的优化是需要清楚数据库选择时的性能表现，例如COUNT(*)可能很快也可能很慢，要看你选用什么数据库引擎。还有一些其他要考虑的因素，例如数据库在什么时候不用缓存，什么时候存在硬盘上而不存在内存中，什么时候数据库创建临时表等等。剩下的5%就很少会有人碰到了，但Silverton先生恰好在这上面花了大量的时间。我从来就没用过SQL_SAMLL_RESULT。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2.很 …\u003c/strong\u003e\u003c/p\u003e"

"\u003cp\u003e今天再从excel里导入数据到Mysql中的时候，发现一个表里的数据总是导入失败．后来经过查找是用的INNODB表引擎的问题．而换成MYISAM表引擎的话，则不存在此问题．并试图先导入成Myisam表，然后手动修改表引擎为INNODB.结果提示＂MySQL Got error 139 from storage engine＂错误．经google一番发现．是由于INNODB单条记录有8K的限制，而导入的excel表里字段不到20个．内容特别的多的．\u003c/p\u003e\n\u003cp\u003e官方解释如下：\u003c/p\u003e\n\u003cp\u003eSolution:\u003c/p\u003e\n\u003cp\u003e1.divide your table into small ones. If one table contain more than 10 text colums, and the data contain is a little bit long. this error will be thrown out.\u003c/p\u003e\n\u003cp\u003e2.modify InnoDB to MyISAM.Problem description:\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eDescription:\nSince upgrading MySQL from version …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e\u003cstrong\u003e00 – 背景知识\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e– B-Tree \u0026amp; B+Tree\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://en.wikipedia.org/wiki/B%2B_tree\" title=\"B+Tree\"\u003ehttp://en.wikipedia.org/wiki/B%2B_tree\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://en.wikipedia.org/wiki/B-tree\" title=\"B-Tree\"\u003ehttp://en.wikipedia.org/wiki/B-tree\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e– 折半查找(Binary Search)\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://en.wikipedia.org/wiki/Binary_search_algorithm\" title=\"Binary Search\"\u003ehttp://en.wikipedia.org/wiki/Binary_search_algorithm\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e– 数据库的性能问题\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eA. 磁盘IO性能非常低，严重的影响数据库系统的性能。\u003c/p\u003e\n\u003cp\u003eB. 磁盘顺序读写比随机读写的性能高很多。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e– 数据的基本存储结构\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eA. 磁盘空间被划分为许多大小相同的块（Block）或者页(Page).\u003c/p\u003e\n\u003cp\u003eB. 一个表的这些数据块以链表的方式串联在一起。\u003c/p\u003e\n\u003cp\u003eC. 数据是以行（Row）为单位一行一行的存放在磁盘上的块中,如图所示.\u003c/p\u003e\n\u003cp\u003eD. 在访问数据时，一次从磁盘中读出或者写入至少一个完整的Block。\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://www.mysqlops.com/wp-content/uploads/2011/11/fig12.jpg\"\u003e\u003cimg src=\"http://www.mysqlops.com/wp-content/uploads/2011/11/fig12.jpg\" alt=\"\"\u003e\u003c/a\u003e\n                   Fig. 1\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e01 – 数据基本操作的实现\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e基本操作包括：INSERT、UPDATE、DELETE、SELECT。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e– SELECT\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eA. 定位数据\u003c/p\u003e\n\u003cp\u003eB. 读出数据所在的块，对数据 …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e浅谈伪分布式数据库架构\u003c/strong\u003e\u003c/p\u003e\n\u003chr\u003e"

"\u003cp\u003e示意图：\n\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2011/11/mysql-replication-master-slave.jpg\"\u003e\u003cimg src=\"http://blog.haohtml.com/wp-content/uploads/2011/11/mysql-replication-master-slave.jpg\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e在使用MySQL的应用中，如果你的MySQL Server压力逐渐增大，在应用层优化已经到了一定瓶颈时，那么你应该首先考虑 \u003ca href=\"http://dev.mysql.com/doc/refman/5.0/en/replication.html\"\u003eMySQL_Replication\u003c/a\u003e。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e如何同步\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e主库将所有的更新操作，写入二进制日志。\u003c/li\u003e\n\u003cli\u003e从库运行”IO线程”（Slave IO Thread）读取主库的二进制日志。\u003c/li\u003e\n\u003cli\u003e从库运行”SQL线程”（Slave SQL Thread）执行IO线程（Slave IO Thread）读取的日志中的SQL,从而保持和主库的一致。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003e如何分配请求\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e目前，这部分需要在应用层实现。\u003c/li\u003e\n\u003cli\u003e执行更新SQL(UPDATE，INSERT，DELETE)时，请求主库。\u003c/li\u003e\n\u003cli\u003e执行查询SQL(SELECT)时，请求从库。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e所以，当你的应用(Application)SELECT请求所占的比率越大，那么Relication就会越有效。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e相关教程:\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eMySQL传输二进制日志原理:\u003c/p\u003e"

"\u003cp\u003e摘自:\u003c/p\u003e\n\u003cp\u003eMySQL Replication可以很方便的用来做应用的读扩展，也可以帮MySQL实现一定程度的HA方案。MySQL通过\u003ca href=\"http://www.orczhou.com/index.php/2009/04/how-mysql-replication-works/\"\u003e向备库传送二进制日志来实现Replication\u003c/a\u003e，本文将通过二进制日志相关源代码的主要接口来解释：“\u003cstrong\u003eMySQL如何传输二进制日志，是主库推，还是备库拉？MySQL日志传输的实时性如何？\u003c/strong\u003e”。\u003c/p\u003e\n\u003cp\u003e在MySQL Replication结构中，备库端初次通过\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/en/change-master-to.html\"\u003eCHANGE MASTER TO\u003c/a\u003e完成Replication配置，再使用start slave命令开始复制。更细致的，备库通过IO Thread向主库发起读取binlog的请求（COM_BINLOG_DUMP命令），主库收到COM_BINLOG_DUMP请求后，使用单独线程（dump thread）不断向备库IO Thread发送Binlog。示意图：\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2011/11/how_mysql_send_binary_log.jpg\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/how_mysql_send_binary_log.jpg\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e在主库端一旦有新的日志产生后，立刻会发送一次广播，dump线程在收到广播后，则会读取二进制日志并通过网络向备库传输日志，所以这是一个主库向备库不断推送的过程；\u003c/p\u003e\n\u003cp\u003e新日志在产生后，只需一次广播和网络就会立刻（\u0026lt;1ms）向发送到备库，如果主备之间网络较好的话（例 …\u003c/p\u003e"

"\u003cp\u003e在平时被问及最多的问题就是关于 MySQL 数据库性能优化方面的问题，所以最近打算写一个MySQL数据库性能优化方面的系列文章，希望对初中级 MySQL DBA 以及其他对 MySQL 性能优化感兴趣的朋友们有所帮助。\u003c/p\u003e\n\u003cp\u003e这是本系列的第一篇文章：MySQL 数据库性能优化之缓存参数优化\u003c/p\u003e\n\u003cp\u003e数据库属于 IO 密集型的应用程序，其主要职责就是数据的管理及存储工作。而我们知道，从内存中读取一个数据库的时间是微秒级别，而从一块普通硬盘上读取一个IO是在毫秒级别，二者相差3个数量级。所以，要优化数据库，首先第一步需要优化的就是 IO，尽可能将磁盘IO转化为内存IO。\u003cstrong\u003e\u003cem\u003e本文先从 MySQL 数据库IO相关参数（缓存参数）的角度来看看可以通过哪些参数进行IO优化\u003c/em\u003e\u003c/strong\u003e：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003equery_cache_size/query_cache_type （global）\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eQuery cache 作用于整个 MySQL Instance，主要用来缓存 MySQL 中的 ResultSet，也就是一条SQL语句执行的结果集，所以仅仅只能针对select语句。当我们打开了 Query Cache 功能，MySQL在接受到一 …\u003c/p\u003e"

"\u003cp\u003e今天我的服务器突然停止复制了。因为对这块不是很熟悉，就上网学习了一下，发现了一篇好文章。不敢独享，\u003c/p\u003e\n\u003cp\u003e和大家来分享一下。\u003c/p\u003e\n\u003cp\u003e众所周知MySQL5.1的Replication是比较烂的。MySQL的每一个版本更新关于同步方面每次都是可以看到一大堆。但MySQL 5.1性能是比较突出的。所以经不住诱惑使用MySQL 5.1。所以也要经常遇到一些Bug。如：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql\u0026gt; show slave status\\G\n\n*************************** 1. row ***************************\n               Slave_IO_State: Waiting for master to send event\n                  Master_Host: 192.168.10.118\n                  Master_User: repl_wu\n                  Master_Port: 3306\n                Connect_Retry: 30 …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e官方教程： \u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/storage-engines.html#innodb\"\u003ehttp://dev.mysql.com/doc/refman/5.1/zh/storage-engines.html#innodb\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e3.6   InnoDB存储引擎文件\u003c/p\u003e\n\u003cp\u003e之前介绍的文件都是MySQL数据库本身的文件，和存储引擎无关。除了这些文件外，每个表存储引擎还有其自己独有的文件。这一节将具体介绍和InnoDB存储引擎密切相关的文件，这些文件包括重做日志文件、表空间文件。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3.6.1   表空间文件\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eInnoDB存储引擎在存储设计上模仿了Oracle，将存储的数据按表空间进行存放。默认配置下，会有一个初始化大小为10MB、名为ibdata1的文件。该文件就是默认的表空间文件（tablespace file）。你可以通过参数innodb_data_file_path对其进行设置。格式如下：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003einnodb_data_file_path=datafile_spec1[;datafile_spec2]…\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e你也可以用多个文件组成一个表空间，同时制定文件的属性，如：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003e[mysqld]\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003einnodb_data_file_path = …\u003c/p\u003e"

"\u003cp\u003eJust to clarify, there are three sets of file/position coordinates in SHOW SLAVE STATUS:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003eThe position, ON THE MASTER, from which the I/O thread is reading: Master_Log_File/Read_Master_Log_Pos. —–相对于主库,从库读取主库的二进制日志的位置,是IO线程\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eThe position, IN THE RELAY LOGS, at which the SQL thread is executing: Relay_Log_File/Relay_Log_Pos —-相对于从库,是从库的sql线程执行到的位置\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eThe position, ON THE MASTER, at which the SQL thread is executing: Relay_Master_Log_File/Exec_Master_Log_Pos —-相对于主库,是从库的sql线程执行到的位置\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eNumbers 2) …\u003c/p\u003e"

"\u003cp\u003e作/译者：叶金荣（Email: \u003cimg src=\"http://imysql.cn/files/pictures/email.gif\" alt=\"\"\u003e），来源：\u003ca href=\"http://imysql.cn/\"\u003ehttp://imysql.cn\u003c/a\u003e，转载请注明作/译者和出处，并且不能用于商业用途，违者必究。\u003c/p\u003e\n\u003cp\u003e并不是所有MySQL都运行在Linux下，windows下也需要做例行备份，下面是用bat脚本做自动化备份的例子，大家可以参考下。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003erem\nrem C:\\Program Files\\WinRAR 需要放到 path 下，才能调用rar cli工具\nrem\nrem 跳转到工作目录下\nf:\ncd f:\\DBBAK\nrem 设置变量：备份文件名\nSET BAK_FILE=MY_DBBAK_%date:~0,-4%.sql\nrem 设置变量：日志文件名\nSET LOG_FILE=MY_DBBAK.log\nrem 记录日志\necho \u0026#34;%date%\u0026#34; \u0026gt;\u0026gt; %LOG_FILE%\nrem 开始做备份\nmysqldump --default-character-set=utf8 -hlocalhost -uroot -R --triggers --single-transaction -B mydb \u0026gt; %BAK_FILE%\nrem …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e\u003cstrong\u003eReplication 线程\u003c/strong\u003e\nMysql的 Replication 是一个异步的复制过程，从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在 Slave 端，另外一个线程(IO线程)在 Master 端。\u003c/p\u003e\n\u003cp\u003e要实现 MySQL 的 Replication ，首先必须打开 Master 端的Binary Log(mysql-bin.xxxxxx)功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全 顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用 “—log-bin” 参数选项，或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加 “log-bin” 参数项。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMySQL 复制的基本过程如下：\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003eSlave 上面的IO线 …\u003c/p\u003e\u003c/li\u003e\u003c/ol\u003e"

"\u003cp\u003e在执行查询的时候,有时候用show processlist命令查看有过多的进程,造成mysql假死的状态,这个时候可以将一些僵死的进程杀掉.恢复正常状态\n找到语句的 thread id\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysqladmin -uroot -proot kill xxxxx\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e如果是系统里的mysql进程的话,可以参考:\u003c/p\u003e"

"\u003cp\u003e1.修改root用户口令，删除空口令\n2.删除默认数据库和数据库用户\n3.改变默认mysql管理员帐号\n4.关于密码的管理\n5.使用独立用户运行msyql\n6.禁止远程连接数据库\n7.限制连接用户的数量\n8.用户目录权限限制\n9.命令历史记录保护\n10.禁止MySQL对本地文件存取\n11.MySQL服务器权限控制\n12.使用chroot方式来控制MySQL的运行目录\n13.关闭对无关的Web程序访问的支持\n14.数据库备份策略\n15. Mysqld安全相关启动选项\n16.information_schema 安全\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1.修改root用户口令，删除空口令\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e缺省安装的MySQL的root用户是空密码的，为了安全起见，必须修改为强密码，所谓的强密码，至少8位，由字母、数字和符号组成的不规律密码。使用MySQL自带的命令mysaladmin修改root密码，同时也可以登陆数据库，修改数据库mysql下的user表的字段内容，修改方法如下所示：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e# /usr/local/mysql/bin/mysqladmin -u root password “upassword” //使 …\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cp\u003eFacebook的用户每天创造大量的数据，为了确保数据可靠的存储，我们每天进行数据备份.我们通过将原来的逻辑备份改成定制化的物理备份,显著地提升了备份的速度(不增加体积的情况下).\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e从mysqldump到Xtrabackup\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e我们使用mysqldump来进行每日的数据库备份,mysqldump对数据进行逻辑备份,就像应用访问数据库那样,mysqldump以SQL语句的方式从数据库中读取一张张表,将表结构和数据转保存到文本文件.mysqldump最大的问题是速度太慢(对于我们的一些大的数据库,通常要花24小时,甚至更久),并且以SQL语句的方式读取数据可能造成磁盘的随机读,这就会造成主机的load增大,影响性能.对于时间太长,我们可以跑多个实例来并发的做备份,这能缩短备份的时间,但是会造成更多的load,更影响主机的性能.\u003c/p\u003e\n\u003cp\u003e另外一个可行的备份方式是进行物理备份(我们称之为二进制备份,binary backup),通过操作系统层面,读取数据库磁盘文件,而非通过SQL语句.这样的话在备份的过程中,数据不能像SQL读取的时候保持事务上一致的.只有当备份的数据文件在数据库里复原了,他们才又一致 …\u003c/p\u003e"

"\u003cp\u003e用户信息表（t_user_info）\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e字段名称\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e字节数\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e类型\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e描述\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eUser_id\u003c/p\u003e\n\u003cp\u003e4\u003c/p\u003e\n\u003cp\u003euint32\u003c/p\u003e\n\u003cp\u003e用户编号（主键）\u003c/p\u003e\n\u003cp\u003eUser_name\u003c/p\u003e\n\u003cp\u003e20\u003c/p\u003e\n\u003cp\u003eChar[20]\u003c/p\u003e\n\u003cp\u003e名称\u003c/p\u003e\n\u003cp\u003eMsg_count\u003c/p\u003e\n\u003cp\u003e4\u003c/p\u003e\n\u003cp\u003euint32\u003c/p\u003e\n\u003cp\u003e发布消息数量,可以作为t_msg_info水平切分新表的auto_increment\u003c/p\u003e\n\u003cp\u003eFans_count\u003c/p\u003e\n\u003cp\u003e4\u003c/p\u003e\n\u003cp\u003euint32\u003c/p\u003e\n\u003cp\u003e粉丝数量\u003c/p\u003e\n\u003cp\u003eFollow_count\u003c/p\u003e\n\u003cp\u003e4\u003c/p\u003e\n\u003cp\u003eUint32\u003c/p\u003e\n\u003cp\u003e关注对象数量\u003c/p\u003e\n\u003cp\u003e备注：以User_id取模分表\u003c/p\u003e\n\u003cp\u003e用户之间关系表（t_user_relation）,必须有关注与被关注的关系\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e字段名称\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e字节数\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e类型\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e描述\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eUser_id\u003c/p\u003e\n\u003cp\u003e4\u003c/p\u003e\n\u003cp\u003euint32\u003c/p\u003e\n\u003cp\u003e用户编号（联合主键）\u003c/p\u003e\n\u003cp\u003eFollow_id\u003c/p\u003e\n\u003cp\u003e4\u003c/p\u003e\n\u003cp\u003euint32\u003c/p\u003e\n\u003cp\u003e被关注者编号（联合主键）\u003c/p\u003e\n\u003cp\u003eType\u003c/p\u003e\n\u003cp\u003e1\u003c/p\u003e\n\u003cp\u003eUint8\u003c/p\u003e\n\u003cp\u003e关系类型（0，粉丝；1，关注）\u003c/p\u003e\n\u003cp\u003e备注：关系是单向的，以User_id取模分表\u003c/p\u003e\n\u003cp\u003e用户消息索引表（t_uer_msg_index）\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e字段名称\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e字节数\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e类型\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e描述\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eUser_id\u003c/p\u003e\n\u003cp\u003e4\u003c/p\u003e\n\u003cp\u003euint32\u003c/p\u003e\n\u003cp\u003e用户编号（联合主键）\u003c/p\u003e\n\u003cp\u003eAuthor_id\u003c/p\u003e\n\u003cp\u003e4\u003c/p\u003e\n\u003cp\u003euint32\u003c/p\u003e\n\u003cp\u003e消息发布者编号（可能是被关注者，也可能是自己）（联合主键） …\u003c/p\u003e"

"\u003cblockquote\u003e\n\u003cp\u003e[root@localhost ~]$ uname -r\n2.6.9-22.ELsmp\u003c/p\u003e\n\u003cp\u003e[root@localhost ~]$ /usr/local/mysql/bin/mysqladmin version -uroot -p\nEnter password:\n/usr/local/mysql/bin/mysqladmin  Ver 8.42 Distrib 5.1.22-rc, for redhat-linux-gnu on x86_64\nCopyright (C) 2000-2006 MySQL AB\nThis software comes with ABSOLUTELY NO WARRANTY. This is free software,\nand you are welcome to modify and redistribute it under the GPL license\u003c/p\u003e\n\u003cp\u003eServer version          5.1.22-rc-log\nProtocol version        10\nConnection              Localhost …\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e生产环境下建议关闭此功能，因绝大部分场景下此选项会产生效率低下问题。\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e\u003cstrong\u003equery_cache_size = 64M\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e指定MySQL查询缓冲区的大小。可以通过在MySQL控制台执行以下命令观察：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e# \u0026gt; SHOW VARIABLES LIKE ‘%query_cache%’;\n# \u0026gt; SHOW STATUS LIKE ‘Qcache%’;\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e# 如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不够的情况;\n如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓冲;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eQcache_free_blocks\u003c/strong\u003e，如果该值非常大，则表明缓冲区中碎片很多。\u003c/p\u003e\n\u003cp\u003e“Qcache_free_blocks”：Query Cache 中目前还有多少剩余的blocks。如果该值显示较大，则说明Query Cache 中的内存碎片较多了，可能需要寻找合适的机会进行整理。\n● “Qcache_free_memory”：Query Cache 中目前剩余的内存大小。通过这个参数我们可以较为准确的观察出当前系统中的Query …\u003c/p\u003e"

"\u003cp\u003e在Centos5.6下通过验证！\u003c/p\u003e\n\u003cp\u003e官方网站：\u003c/p\u003e\n\u003cp\u003e很早之前，就看到了通过mysql UDF 更新memcached ，原来也研究过一段时间，只是没有来得及写个文档，导致后来工作中，经常要google，搜索其安装，使用的方法，刹时麻烦，今天总结一下：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1：mysql memcached UD介绍\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003emysql memcached UDF 其实就是通过libmemcached来使用memcache的一系列函数，通过这些函数，你能 对memcache进行get, set, cas, append, prepend, delete, increment, decrement objects操作，如果我们通过mysql trigger来使用这些函数，那么就能通过mysql更好的，更自动的管理memcache!下载地址：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2:安装方法：\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e1）安装memcache和memcached\u003c/p\u003e\n\u003cp\u003e参考：\u003c/p\u003e\n\u003cp\u003e2）安装libmemcached（）\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e$ wget \u003ca href=\"http://download.tangent.org/libmemcached-0.31.tar.gz\"\u003ehttp://download.tangent.org/libmemcached-0.31.tar.gz\u003c/a\u003e\n$ tar -xzvf …\u003c/p\u003e\u003c/blockquote\u003e"

""

"\u003cp\u003e曾经发文介绍过，DROP table XXX ,特别是碰到大表时，\u003c/p\u003e\n\u003cp\u003e在DROP TABLE 过程中，所有操作都会被HANG住。\n这是因为INNODB会维护一个全局独占锁（在table cache上面），直到DROP TABLE完成才释放。\n在我们常用的ext3,ext4，ntfs文件系统，要删除一个大文件（几十G，甚至几百G）还是需要点时间的。\n下面我们介绍一个快速DROP table 的方法； 不管多大的表,INNODB 都可以很快返回，表删除完成；\n实现：巧用LINK（硬链接）\u003c/p\u003e\n\u003cp\u003e实测：\u003c/p\u003e\n\u003cp\u003e: test 21:38:00\u0026gt; show table status like ‘tt’ \\G\n*\u003cstrong\u003e*\u003c/strong\u003e*\u003cstrong\u003e*\u003c/strong\u003e*\u003cstrong\u003e*\u003c/strong\u003e*\u003cstrong\u003e*\u003c/strong\u003e*\\\u003cem\u003e* 1. row ***\u003cstrong\u003e*\u003c/strong\u003e*\u003cstrong\u003e*\u003c/strong\u003e*\u003cstrong\u003e*\u003c/strong\u003e*\u003cstrong\u003e*\u003c/strong\u003e\u003c/em\u003e\nName: tt\nEngine: InnoDB\nVersion: 10\nRow_format: Compact\nRows: 151789128\nAvg_row_length: 72\nData_length: 11011096576\nMax_data_length: 0\nIndex_length: 5206179840\nData_free: …\u003c/p\u003e"

"\u003cp\u003e测试背景介绍 ：两台机器AB,A机器使用常规引擎innodb，B使用infobright，测试数据量10亿，平均分散到两台机器，基于各种因素，A的数据分成了24个表，即每小时一个。\u003c/p\u003e\n\u003cp\u003e1.infobright和myisampack的压缩性能对比：\u003c/p\u003e\n\u003cp\u003e数据加载完成后首先alter table XXX engine=myisam使用mysqlchk进行压缩，压缩后每天有45G左右的数据，infobright存储要7~8G，压缩性能差异近80%\u003c/p\u003e\n\u003cp\u003e2.infrobright和myisam查询效率对比：\u003c/p\u003e\n\u003cp\u003e两台机器上面执行相同的sql语句：select count(1),type from table_name group by type;\u003c/p\u003e\n\u003cp\u003eA（innodb）运行情况:\u003cimg src=\"http://60.29.242.49/wp-content/uploads/2010/03/image00103-29-10-45-541.jpg\" alt=\"image001(03-29-10-45-54)\"\u003e\u003c/p\u003e\n\u003cp\u003eB（infobright）运行情况:\u003c/p\u003e\n\u003cp\u003e\u003cimg src=\"http://60.29.242.49/wp-content/uploads/2010/03/image00203-29-10-45-54.jpg\" alt=\"image002(03-29-10-45-54)\"\u003e\u003c/p\u003e\n\u003cp\u003e由于innodb存储时需要改成myisam引擎并进行压缩，所以耗费了cpu不少资源，除此之外，mysql本身运行的资源消耗基本无区别。\u003c/p\u003e\n\u003cp\u003e在执行时间上，infobright耗时(3 min 31.37 sec) ，myisam耗时（1 min 45.38 sec)，但由于A是散成了24个表，所以耗 …\u003c/p\u003e"

"\u003cp\u003eInfobright是开源的\u003ca href=\"http://www.oschina.net/p/mysql\"\u003eMySQL\u003c/a\u003e数据仓库解决方案，引入了列存储方案，高强度的数据压缩，优化的统计计算(类似sum/avg/group by之类)，下面是Infobright的架构图：\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2011/05/03055857_9B9X.png\"\u003e\u003cimg src=\"http://blog.haohtml.com/wp-content/uploads/2011/05/03055857_9B9X.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e安装方法请参考:\u003c/p\u003e\n\u003cp\u003e相关应用案例:\u003c/p\u003e\n\u003cp\u003e相关文章:\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e1.RESET MASTER\u003c/strong\u003e\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e****可以删除列于索引文件中的所有二进制日志，把二进制日志索引文件重新设置为空，并创建一个新的二进制日志文件\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2.PURGE MASTER LOGS\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e语法\nPURGE {MASTER | BINARY} LOGS TO ‘\u003cem\u003elog_name\u003c/em\u003e‘\nPURGE {MASTER | BINARY} LOGS BEFORE ‘\u003cem\u003edate\u003c/em\u003e‘\n用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除，这样被给定的日志成为第一个。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e(1).用reset master命令删除所有日志，新日志重新从000001开始编号\u003c/p\u003e\n\u003cp\u003e(2).用purge master logs to ‘mysq-bin.*\u003cstrong\u003e*\u003c/strong\u003e’ 命令可以删除指定编号前的所有日志\u003c/p\u003e\n\u003cp\u003e(3).用purge master logs to before ‘YYYY-MM-DD HH24:MI:SS’命令可以删除’YYYY-MM-DD HH24:MI:SS’之前的产生的所有日志\u003c/p\u003e\n\u003cp\u003e(4).可以在my.cnf中指定–expire_logs_days=#，此参数设置了binlog日志 …\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cp\u003e注意在进行配置前,请确保相应的3306端口可以端口: \u003ca href=\"http://blog.haohtml.com/archives/7726\"\u003ehttp://blog.haohtml.com/archives/7726\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e刚刚抽空做了一下MYSQL 的主主同步。\n把步骤写下来，至于会出现的什么问题，以后随时更新。这里我同步的数据库是TEST\n\u003cstrong\u003e1、环境描述。\u003c/strong\u003e\n主机：192.168.0.231（A）\n主机：192.168.0.232（B）\nMYSQL 版本为5.1.21\n\u003cstrong\u003e2、授权用户。\u003c/strong\u003e\nA：\nmysql\u0026gt; grant replication slave,file on *.* to ‘repl1’@’192.168.0.232’ identified by ‘123456’;\nQuery OK, 0 rows affected (0.00 sec)\u003c/p\u003e\n\u003cp\u003emysql\u0026gt; flush privileges;\nQuery OK, 0 rows affected (0.00 sec)\nB：\nmysql\u0026gt; grant replication slave,file on *.* to ‘repl2’@’192.168.0.231’ identified by ‘123456’; …\u003c/p\u003e"

"\u003cp\u003e今日在修改过去的一个程序时, 不小时设置了错误的删除条件,导致几十万条数据丢失, 同时数据库没有打开日志和备份, 请教大侠,有什么方法可以恢复数据.\u003c/p\u003e\n\u003cp\u003e我已经将对应的三个表文件. MYD,MYI,frm备份出来, 查看了一下文件大小, 好象数据并未丢失, 估计只是设置了删除状态. 使用uedit32打开MYD文件,还可以辨识出数据的确还在. 我想应该是做了标记,将这些数据设置为删除状态,数据并未真正删除掉, 不知道现在可有现成的工具可以通过该数据文件将数据恢复. 如果没有的话, 可能就只能研究一下myisam表的结构,自己尝试恢复了!\u003c/p\u003e\n\u003cp\u003e希望各位大侠救我!\u003c/p\u003e\n\u003cp\u003e简单说一下吧:\u003c/p\u003e\n\u003cp\u003emysql中的myisam表在正常情况下执行delete 指定删除的记录实际上只是在索引文件中做了删除标记,同时也将数据文件中对记录的头几个字节改写, 但这几个字节具体的与入内容不清楚.(见下方)\u003c/p\u003e\n\u003cp\u003e通过我研究数据文件, 发现了几种数据类型保存的格式.\u003c/p\u003e\n\u003cp\u003evarchar: 在该类型数据开始的位置有一个字节来指出后面多少个字节是该字段的内容, 但是有一个例外就是如果后面的内容与varchar字段指定的长度完全相等时,就没有开头 …\u003c/p\u003e"

"\u003cp\u003e环境：\nMysql: 5.1.37 dual master(节点为A,B)\nOS: centos5.3 x64\u003c/p\u003e\n\u003cp\u003e由于我今天突然将重新启动从服务，导致MYSQL一边的复制失败，如下：\u003c/p\u003e\n\u003cp\u003e从服务器节点A启动slave就报下面的错误：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e090910 22:47:18 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)\n090910 22:47:18 [ERROR] Got fatal error 1236: ‘Client requested master to start replication from impossible position’ from master when reading data from binary log\n090910 22:47:18 [Note] Slave I/O thread exiting, read up to log …\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cp\u003e有关mysql主从复制原理请参考： \u003ca href=\"http://blog.haohtml.com/archives/11507\"\u003ehttp://blog.haohtml.com/archives/11507\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlave_IO_State：\u003c/strong\u003e 等待 master 发生事件\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMaster_Host：\u003c/strong\u003e 当前的主服务器主机\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMaster_User：\u003c/strong\u003e 被用于连接主服务器的当前用户\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMaster_Port：\u003c/strong\u003e 当前的主服务器接口\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eConnect_Retry：\u003c/strong\u003e master-connect-retry选项的当前值\u003c/p\u003e\n\u003cp\u003eMaster_Log_File：SLAVE中的I/O线程当前正在读取的主服务器二进制日志文件的名称\u003c/p\u003e\n\u003cp\u003eRead_Master_Log_Pos：在当前的主服务器二进制日志中，SLAVE中的I/O线程已经读取的位置\u003c/p\u003e\n\u003cp\u003eRelay_Log_File：SQL线程当前正在读取和执行的中继日志文件的名称\u003c/p\u003e\n\u003cp\u003eRelay_Log_Pos：在当前的中继日志中，SQL线程已读取和执行的位置\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRelay_Master_Log_File：由SQL线程执行的包含多数近期事件的主服务器二进制日志文件的名称\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSlave_IO_Running：I/O …\u003c/strong\u003e\u003c/p\u003e"

"\u003ch1 id=\"b树\"\u003eB树\u003c/h1\u003e\n\u003cp\u003e即二叉搜索树：\u003c/p\u003e\n\u003cp\u003e1.所有非叶子结点至多拥有两个儿子（Left和Right）；\u003c/p\u003e\n\u003cp\u003e2.所有结点存储一个关键字；\u003c/p\u003e\n\u003cp\u003e3.非叶子结点的左指针指向小于其关键字的子树，右指针指向大于其关键字的子树；\u003c/p\u003e\n\u003cp\u003e如：\u003cimg src=\"http://www.haohtml.com/uploads/allimg/101201/092542M15-0.jpg\" alt=\"\"\u003e\u003c/p\u003e\n\u003cp\u003eB树的搜索，从根结点开始，如果查询的关键字与结点的关键字相等，那么就命中；否则，如果查询关键字比结点关键字小，就进入左儿子；如果比结点关键 字大，就进入右儿子；如果左儿子或右儿子的指针为空，则报告找不到相应的关键字；\u003c/p\u003e\n\u003cp\u003e如果B树的所有非叶子结点的左右子树的结点数目均保持差不多（平衡），那么B树的搜索性能逼近二分查找；但它比连续内存空间的二分查找的优点是，改变B树 结构（插入与删除结点）不需要移动大段的内存数据，甚至通常是常数开销；\u003c/p\u003e\n\u003cp\u003e如：\u003c/p\u003e\n\u003cp\u003e\u003cimg src=\"http://www.haohtml.com/uploads/allimg/101201/0925421M8-1.jpg\" alt=\"\"\u003e\u003c/p\u003e\n\u003cp\u003e但B树在经过多次插入与删除后，有可能导致不同的结构\u003c/p\u003e\n\u003cp\u003e\u003cimg src=\"http://www.haohtml.com/uploads/allimg/101201/092542L35-2.jpg\" alt=\"\"\u003e\u003c/p\u003e\n\u003cp\u003e右边也是一个B树，但它的搜索性能已经是线性的了；同样的关键字集合有可能导致不同的树结构索引；所以，使用B树还要考虑尽可能让B树保持左图的结 构，和避免右图的结构，也就是所谓的“平衡”问题；\u003c/p\u003e\n\u003cp\u003e实际使用的B树都是在原B树的基础上加上平衡算法，即“平衡二叉树”；如何保持B树结点分布均匀的平衡算法是平衡二叉树的关 …\u003c/p\u003e"

"\u003cp\u003eMySQL数据库性能优化是本文的主要核心，将从数据库的优化设计，到具体的操作。好的优化能使服务器性能提升较大的空间，希望本文对大家有所帮助。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1. MySQL性能优化简介\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e在Web应用程序体系架构中，数据持久层(通常是一个关系数据库)是关键的核心部分，它对系统的性能有非常重要的影响。MySQL是目前使用最多的开源数据库，但是MySQL数据库的默认设置性能非常的差，仅仅是一个玩具数据库。因此在产品中使用MySQL数据库必须进行必要的优化。\u003c/p\u003e\n\u003cp\u003e优化是一个复杂的任务，本文描述MySQL相关的数据库设计和查询优化，服务器端优化，存储引擎优化。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. 数据库设计和查询优化\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e在MySQL性能优化中，首先要考虑的就是Database Schema设计，这一点是非常重要的。一个糟糕的Schema设计即使在性能调优的MySQL Server上运行，也会表现出很差的性能;和Schema相似，查询语句的设计也会影响MySQL的性能，应该避免写出低效的SQL查询。这一节将详细讨论这两方面的优化。\u003c/p\u003e\n\u003cp\u003e2.1 Schema Design\u003c/p\u003e\n\u003cp\u003eSchema的优化取决于将要运行什么样的query，不同的query会有不同 …\u003c/p\u003e"

"\u003cp\u003emysql的单点一直是一个让人很烦恼的事情，特别是master的单点。\u003c/p\u003e\n\u003cp\u003e现在外面的解决方案主要如下： 双master方案，heartbert(HA)+rhcs(分布式文件系统)，heartbert(HA)+DRBD.\u003c/p\u003e\n\u003cp\u003e双master存在的问题是master有2个IP，这样意为着前端需要指向2个的masterIP，同时bin-log也是双向同步的，会不会比单向同步的量更多呢？\u003c/p\u003e\n\u003cp\u003e第二种方案是挺不错的，但是必须要分布式文件系统，要是实在不行就可以用NFS来代替，但是这样存在的问题就是数据文件是单点，所以必须使用分布式文件系统。\u003c/p\u003e\n\u003cp\u003e第三种是关键是DRBD，这个是在网络层做RAID1，在A机器上收到数据后DRBD会写到本地硬盘上，同时通过网络传输到另外一台机器上。这样保证了2台机器的一致。特别是DRBD传输的时候有多种协议可以选择，但是一般看到网上大家都是使用协议C（C表示收到远程主机的写入确认后,视为写入完成）\nDRBD的架构如下：\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2010/08/drbd.png\"\u003e\u003cimg src=\"http://blogx.haohtml.com/wp-content/uploads/2010/08/drbd.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e今天在high scalability有个文档专门比较各种mysql HA的方案。基本上大家可以根据这个比较来做自己合适的的MySQL HA了\n\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2010/08/different-ha.png\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/different-ha.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e可能很多读者朋友在网上或者杂志上面都已经多次见到关于数据切分的相关文章了， 只不过在有些文章中称之为数据的 Sharding 。其实不管是称之为数据的 Sharding 还是数据的切分，其概念都是一样的。简单来说，就是指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载的效果。 数据的切分同时还可以提高系统的总体可用性，因为单台设备 Crash 之后，只有总体数据的某部分不可用，而不是所有的数据。\u003c/p\u003e\n\u003cp\u003e数据的切分（ Sharding ）根据其切分规则的类型，可以分为两种切分模式。\n\u003cstrong\u003e垂直（纵向）切分:\u003c/strong\u003e 一种是按照不同的表（或者 Schema ）来切分到不同的数据库（主机）之上，这种切可以称之为数据的垂直（纵向）切分；\n\u003cstrong\u003e水平（横向）切分:\u003c/strong\u003e 另外一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面，这种切分称之为数据的水平（横向）切分。\u003c/p\u003e\n\u003cp\u003e垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所 …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003eI. Strict Mode阐述\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e根据 mysql5.0以上版本 strict mode (STRICT_TRANS_TABLES) 的限制：\u003c/p\u003e\n\u003cp\u003e1).不支持对not null字段插入null值\u003c/p\u003e\n\u003cp\u003e2).不支持对自增长字段插入”值，可插入null值\u003c/p\u003e\n\u003cp\u003e3).不支持 text 字段有默认值\u003c/p\u003e\n\u003cp\u003e看下面代码：(第一个字段为自增字段)\u003c/p\u003e\n\u003cp\u003e$query=”insert into demo values(”,’$firstname’,’$lastname’,’$sex’)”;\u003c/p\u003e\n\u003cp\u003e上边代码只在非strict模式有效。\u003c/p\u003e\n\u003cp\u003e$query=”insert into demo values(NULL,’$firstname’,’$lastname’,’$sex’)”;\u003c/p\u003e\n\u003cp\u003e上边代码只在strict模式有效。把空值”换成了NULL.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eII.让数据库支持Strict Mode\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e1.对数据库结构进行以下改进来支持strict mode:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e给所有not null字段都设置非null默认值，字符串默认值为 ”，数值默认值为 0，日期默认值为 ‘0000-00-00 00:00:00’\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e去掉text字段的默认值\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e规范化改进: …\u003c/p\u003e\u003c/li\u003e\u003c/ol\u003e"

"\u003cp\u003e对于任何一个数据库管理系统来说，内存的分配使用绝对可以算的上是其核心之一了，所以很多希望更为深入了解某数据库管理系统的人，都会希望一窥究竟，我也不例外。\u003c/p\u003e\n\u003cp\u003e从内存的使用方式MySQL 数据库的内存使用主要分为以下两类\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e线程独享内存\u003c/li\u003e\n\u003cli\u003e全局共享内存\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e今天这篇文章暂时先分析 MySQL 中主要的 “线程独享内存” 的。\u003c/p\u003e\n\u003cp\u003e在 MySQL 中，线程独享内存主要用于各客户端连接线程存储各种操作的独享数据，如线程栈信息，分组排序操作，数据读写缓冲，结果集暂存等等，而且大多数可以通过相关参数来控制内存的使用量。\u003c/p\u003e\n\u003cp\u003e**线程栈信息使用内存(thread_stack)：**主要用来存放每一个线程自身的标识信息，如线程id，线程运行时基本信息等等，我们可以通过 thread_stack 参数来设置为每一个线程栈分配多大的内存。\u003c/p\u003e\n\u003cp\u003e**排序使用内存(sort_buffer_size)：**MySQL 用此内存区域进行排序操作（filesort），完成客户端的排序请求。当我们设置的排序区缓存大小无法满足排序实际所需内存的时候，MySQL 会将数据写入磁盘文件来完成排序。由于磁盘和内存的读写性能完全不在一个数量级， …\u003c/p\u003e"

"\u003cp\u003emysql服务器为主-从配置时,发现从MySQL Slave未和主机同步，查看Slave状态：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003emysql\u0026gt; show slave statusG\nSlave_IO_Running: Yes\nSlave_SQL_Running: No\nLast_Errno: 1062\n….\nSeconds_Behind_Master:NULL\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003e原因：\u003c/strong\u003e\n1.程序可能在slave上进行了写操作\n2.也可能是slave机器重起后，事务回滚造成的.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e解决办法I：\u003c/strong\u003e\n1.首先停掉Slave服务：\u003cstrong\u003eslave stop\u003c/strong\u003e\n到主服务器上查看主机状态：\n记录File和Position对应的值。\n3.到slave服务器上执行手动同步：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003emysql\u0026gt; show master status;\n+——————+———–+————–+——————+\n| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |\n+——————+———–+————–+——————+\n| mysql-bin.000020 | 135617781 | | | …\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cp\u003e服务器生成的二进制日志文件写成二进制格式。要想检查这些文本格式的文件，应使用mysqlbinlog实用工具。\n应这样调用mysqlbinlog：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eshell\u0026gt; mysqlbinlog [options] log-files…\n例如，要想显示二进制日志binlog.000003的内容，使用下面的命令：\u003c/p\u003e\n\u003cp\u003eshell\u0026gt; mysqlbinlog binlog.0000003\n输出包括在binlog.000003中包含的所有语句，以及其它信息例如每个语句花费的时间、客户发出的线程ID、发出线程时的时间戳等等。\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e通常情况，可以使用mysqlbinlog直接读取二进制日志文件并将它们用于本地MySQL服务器。也可以使用–read-from-remote-server选项从远程服务器读取二进制日志。\u003c/p\u003e\n\u003cp\u003e当读取远程二进制日志时，可以通过连接参数选项来指示如何连接服务器，但它们经常被忽略掉，除非你还指定了–read-from-remote-server选项。这些选项是–host、–password、–port、–protocol、–socket和–user。\u003c/p\u003e\n\u003cp\u003e还可以使用mysqlbinlog来 …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003eMySQL程序剖析 （Profiling）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e我们将要详细的讲到MySQL的剖析(Profiling),因为它很少依赖于你的应用。应用和服务器 级别的剖析有的时候都是有必要的。虽然应用级别的剖析可以给你整个应用性能的总揽。，但是对MySQL的剖析提供了信息是服务器级别所提供不了的。比如， 对PHP代码进行剖析不会显示MySQL有多少行语句执行了。\u003c/p\u003e\n\u003cp\u003e与应用剖析一样，目标是找出MySQL哪部分消耗过多的时间。我们不会剖析MySQL源码的，虽然有的 时候定制化MySQL安装很有用，但是这是另一本书的主题了。所替代的是，我们将教你一些可以技术来获取和分析不同种类的MySQL执行语句的信息。\u003c/p\u003e\n\u003cp\u003e你可以用在任意的颗粒级别以满足你的需求：你可能对整个服务器进行剖析或者单独检查一个语句或者一组语 句。下列信息你可以一点点的收集：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMySQL经常访问的那些数据\u003c/li\u003e\n\u003cli\u003eMySQL经常执行语句的类型\u003c/li\u003e\n\u003cli\u003eMySQL线程大部分时间的状态\u003c/li\u003e\n\u003cli\u003eMySQL经常执行语句的子系统\u003c/li\u003e\n\u003cli\u003eMySQL执行语句所访问的数据类型\u003c/li\u003e\n\u003cli\u003e不同活动的类型，比如扫描索引。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e我们先从范围最广的剖析开始，那就是服务器剖析，将教你更多细节。 …\u003c/p\u003e"

"\u003cp\u003e查看索引使用情况\u003c/p\u003e\n\u003cp\u003e如果索引正在工作， Handler_read_key 的值将很高，这个值代表了一个行被索引值读的次数，很低的值表明增加索引得到的性能改善不高，因为索引并不经常使用。\u003c/p\u003e\n\u003cp\u003eHandler_read_rnd_next 的值高则意味着查询运行低效，并且应该建立索引补救。这个值的含义是在数据文件中读下一行的请求数。如果你正进行大量的表扫描，该值较高。通常说明表索引不正确或写入的查询没有利用索引。\u003c/p\u003e\n\u003cp\u003e语法：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003emysql\u0026gt; show status like ‘Handler_read%’;\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e有关更多MySQL之Handler_read_*介绍参考：\u003c/p\u003e"

"\u003cp\u003e当使用mysql做数据库还原的时候，由于有些数据很大，总是失败并决 MySQL server has gone away之类的信息，并自动重新连接数据库且自动继续执行恢复操作，此时没有办法重新指定字符集，容易出现乱码，导致数据库恢复失败，只需要修改max_allowed_packet 参数的值即可.\u003c/p\u003e\n\u003cp\u003emysql根据配置文件会限制server接受的数据包大小。\u003c/p\u003e\n\u003cp\u003e有时候大的插入和更新会被max_allowed_packet 参数限制掉，导致失败。\u003c/p\u003e\n\u003ch2 id=\"1-方法1\"\u003e1） 方法1\u003c/h2\u003e\n\u003cp\u003e可以编辑my.cnf来修改（windows下my.ini）,在[mysqld]段或者mysql的server配置段进行修改。\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emax_allowed_packet = 20M\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e如果找不到my.cnf可以通过\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql --help | grep my.cnf\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e去寻找my.cnf文件。\u003c/p\u003e\n\u003ch2 id=\"2-方法2\"\u003e2） 方法2\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e（很妥协，很纠结的办法）\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e进入mysql server\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql -h 主机 -u 账号 -p密码\nset global max_allowed_packet = 2*1024*1024*10\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e然后关闭掉这此mysql server链 …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"https://dev.mysql.com/doc/refman/5.7/en/show-profile.html\"\u003ehttps://dev.mysql.com/doc/refman/5.7/en/show-profile.html\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e此功能将在新版本中被移除，性能分析使用新方法来代替。(官方提供了此命令的使用方法, 对于 show profile for query ID / show profile  \u003cstrong\u003eCPU\u003c/strong\u003e for query ID 结果中每项的说明信息请参考： \u003ca href=\"https://www.cnblogs.com/itcomputer/articles/5056127.html\"\u003ehttps://www.cnblogs.com/itcomputer/articles/5056127.html\u003c/a\u003e）\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eNote\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThese statements are deprecated and will be removed in a future MySQL release. Use the Performance Schema instead; see \u003ca href=\"https://dev.mysql.com/doc/refman/5.7/en/performance-schema.html\" title=\"Chapter 25 MySQL Performance Schema\"\u003eChapter 25, \u003cem\u003eMySQL Performance Schema\u003c/em\u003e\u003c/a\u003e.\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e对于新版本我们也可以直接查询  \u003ccode\u003eINFORMATION_SCHEMA\u003c/code\u003e \u003ca href=\"https://dev.mysql.com/doc/refman/8.0/en/profiling-table.html\" title=\"25.20 The INFORMATION_SCHEMA PROFILING Table\"\u003e\u003ccode\u003ePROFILING\u003c/code\u003e\u003c/a\u003e . See \u003ca href=\"https://dev.mysql.com/doc/refman/8.0/en/profiling-table.html\" title=\"25.20 The INFORMATION_SCHEMA PROFILING Table\"\u003eSection 25.20, “The INFORMATION_SCHEMA PROFILING …\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e启动、停止 MySQL\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e要启动 MySQL 的方法：（以本文将 MySQL 安装在 /usr/local/mysql 为例）\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e# /usr/local/mysql/share/mysql.server start\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e如果安装目录使用的是默认的话,请使用\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e /usr/local/etc/rc.d/mysql-server start|stop|restart\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e注意在第一次执行前，须将 mysql.server 设成可执行（chmod 744 mysql.server），另外可将这行指令加在 /etc/rc.d/rc.local 档中，让 MySQL 在开机时自动启动。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e要停止 MySQL 的方法：\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e# /usr/local/mysql/bin/mysqladmin shutdown\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e如果你为 MySQL Administrator root 帐号（非作业系统的 root）设了密码，要停止 MySQL 则必须像下列这样做，MySQL 会询问你 root 的密码後才会执行 shutdown 的工作：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e# /usr/local/mysql/bin/mysqladmin -u root …\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cp\u003eMySQL从5.1.4版开始带有一个压力测试工具 \u003cstrong\u003emysqlslap\u003c/strong\u003e，通过模拟多个并发客户端访问 mysql来执行测试，使用起来非常的简单。通过mysqlslap –help可以获得可用的选项，这里列一些主要的参数，更详细的说明参考 \u003ca href=\"http://dev.mysql.com/doc/refman/5.1/en/mysqlslap.html\"\u003e官方手册\u003c/a\u003e。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e–auto-generate-sql, -a\u003c/p\u003e\n\u003cp\u003e自动生成测试表和数据\u003c/p\u003e\n\u003cp\u003e–auto-generate-sql-load-type=type\u003c/p\u003e\n\u003cp\u003e测试语句的类型。取值包括：read，key，write，update和mixed(默认)。\u003c/p\u003e\n\u003cp\u003e–number-char-cols=N, -x N\u003c/p\u003e\n\u003cp\u003e自动生成的测试表中包含多少个字符类型的列，默认1\u003c/p\u003e\n\u003cp\u003e–number-int-cols=N, -y N\u003c/p\u003e\n\u003cp\u003e自动生成的测试表中包含多少个数字类型的列，默认1\u003c/p\u003e\n\u003cp\u003e–number-of-queries=N\u003c/p\u003e\n\u003cp\u003e总的测试查询次数(并发客户数×每客户查询次数)\u003c/p\u003e\n\u003cp\u003e–query=name,-q\u003c/p\u003e\n\u003cp\u003e使用自定义脚本执行测试，例如可以调用自定义的一个存储过程或者sql语句来执行测试。\u003c/p\u003e\n\u003cp\u003e–create-schema\u003c/p\u003e\n\u003cp\u003e测试的schema，MySQL中schema也就是database\u003c/p\u003e\n\u003cp\u003e–commint=N …\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cp\u003e连接mysql server出来这个信息\u003c/p\u003e\n\u003cp\u003e引用\u003c/p\u003e\n\u003cblockquote\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003emessage from server: “Host ‘HP-2B6E9EC1747B’ is blocked because of many connection errors; unblock with ‘mysqladmin flush-hosts\u0026rsquo;”\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e连接次数失败过多,并超过max_connect_erros的值后，服务器会直接拒绝来源机器的所有连接，只要把mysql server默认 max_connect_errors = 10\n把这个值设置大点就好了，记得一定要执行mysqladmin flush-hosts命令来解锁，原来的主机才可以恢复正常连接的．\u003c/p\u003e"

"\u003cp\u003e在MySQL里，我们一般使用 \u003ca href=\"http://dev.mysql.com/doc/refman/5.0/en/show-status.html\"\u003eSHOW STATUS\u003c/a\u003e 查询服务器状态，语法一般来说如下：\u003c/p\u003e\n\u003cp\u003eSHOW [GLOBAL | SESSION] STATUS [LIKE ‘pattern’ | WHERE expr]\u003c/p\u003e\n\u003cp\u003e执行命令后会看到很多内容，其中有一部分是Handler_read_*，它们显示了数据库处理SELECT查询语句的状态，对于调试SQL语句有很大意 义，可惜实际很多人并不理解它们的实际意义，本文简单介绍一下：\u003c/p\u003e\n\u003cp\u003e为了让介绍更易懂，先建立一个测试用的表：\u003c/p\u003e\n\u003cp\u003eCREATE TABLE IF NOT EXISTS \u003ccode\u003efoo\u003c/code\u003e (\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eid\u003c/code\u003e int(10) unsigned NOT NULL auto_increment,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ecol1\u003c/code\u003e varchar(10) NOT NULL,\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003ecol2\u003c/code\u003e text NOT NULL,\u003c/p\u003e\n\u003cp\u003ePRIMARY KEY (\u003ccode\u003eid\u003c/code\u003e),\u003c/p\u003e\n\u003cp\u003eKEY \u003ccode\u003ecol1\u003c/code\u003e (\u003ccode\u003ecol1\u003c/code\u003e)\u003c/p\u003e\n\u003cp\u003e);\u003c/p\u003e\n\u003cp\u003eINSERT INTO `foo` (`id`, `col1`, `col2`) VALUES\n(1, ‘a’, ‘a’),\n(2, ‘b’, ‘b’),\n(3, ‘c’, ‘c’),\n(4, ‘d’, ‘d’), …\u003c/p\u003e"

"\u003cp\u003e对于SQL查询语句对于服务器系统资源的使用情况见：发现瓶颈 – Profiling(程序剖析) -MySQL Profiling\u003c/p\u003e\n\u003cp\u003e网上有很多的文章教怎么配置MySQL服务器，但考虑到服务器硬件配置的不同，具体应用的差别，那些文章的做法只能作为初步设置参考，我们需要根据自己的 情况进行配置优化，好的做法是MySQL服务器稳定运行了一段时间后运行，根据服务器的”状态”进行优化。\u003c/p\u003e\n\u003cp\u003emysql\u0026gt; show global status;\u003c/p\u003e\n\u003cp\u003e可以列出MySQL服务器运行各种状态值，另外，查询MySQL服务器配置信息语句：\u003c/p\u003e\n\u003cp\u003emysql\u0026gt; show variables;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一、慢查询\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003emysql\u0026gt; show variables like ‘%slow%’;\n+——————+——-+\n| Variable_name    | Value |\n+——————+——-+\n| log_slow_queries | ON    |\n| slow_launch_time | 2     |\n+——————+——-+\u003c/p\u003e\n\u003cp\u003emysql\u0026gt; show global status like …\u003c/p\u003e"

"\u003cp\u003eMySQL服务器端的参数有很多，但是对于大多数初学者来说，众多的参数往往使得我们不知所措，但是哪些参数是需要我们调整的，哪些对服务器的性能影响最大呢？对于使用Myisam存储引擎来说，主要有key_buffer_size和table_cache两个参数。对于InnoDB引擎来说主要还是以innodb_开始的参数，也很好辨认。\n查看MySQL参数，可以使用\u003cstrong\u003eshow variables\u003c/strong\u003e和\u003cstrong\u003eshow status\u003c/strong\u003e命令查看，前者查看服务器静态参数，即在数据库启动后不会动态更改的值，比如缓冲区、字符集等。后者查看服务器的动态运行状态信息，即数据库运行期间动态变化的信息，比如锁，当前连接数等。\u003c/p\u003e\n\u003cp\u003ekey_buffer_size这个参数是用来设置索引块（index blocks）缓存的大小，它被所有线程共享，严格说是它决定了数据库索引处理的速度，尤其是索引读的速度。那我们怎么才能知道key_buffer_size的设置是否合理呢，一般可以检查状态值Key_read_requests和Key_reads，比例key_reads / key_read_requests 应该尽可能的低，比 …\u003c/p\u003e"

"\u003cp\u003eMysql5.5慢查询开启有些改变,在my.cnf的 [mysqld]　section 添加以下几行即可．注意一定要在[mysqld]块，否则不起作用.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003elong_query_time = 0.001\nslow-query-log = ON\nslow_query_log_file = /usr/local/mysql/data/slow.log\nlog-queries-not-using-indexes = on\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e===================================================\u003c/p\u003e\n\u003cp\u003emysql有一个功能就是可以log下来运行的比较慢的sql语句，默认是没有这个log的，为了开启这个功能，要修改my.cnf或者在mysql启动的时候加入一些参数。\n如果在my.cnf里面修改，需增加如下几行\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003elong_query_time = 10\nslow_query_log  = /var/log/slow.log\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003elong_query_time 是指执行超过多久的sql会被log下来，这里是10秒。\nslow_query_log  设置把日志写在那里，为空的时 …\u003c/p\u003e"

"\u003cp\u003e一般来说，你有两种可供选择的备份MySQL的方式—-mysqldump 或者mysqlhotcopy。\u003c/p\u003e\n\u003cp\u003emysqldump可以备份各种类型的数据表，但是mysqlhotcopy \u003ca href=\"http://dev.mysql.com/doc/refman/5.0/en/backup.html\"\u003e只适合\u003c/a\u003e 备份MyISAM和ISAM的数据表。所以使用mysqlhotcopy之前，你必须确认你的数据表是不 是有其他的存储引擎(storage engines)的。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHow To：\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003emysqldump -u root -p*** DBNAME | gzip -f\u0026gt;/backup/dbname.’date +%w’.dump.gz\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003emysqlhotcopy DBNAME -u root -p *** /backup\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e**两者速度：**因为 mysqlhotcopy会直接拷贝存储数据的文件，所以其速度是依赖于磁盘操作的速度，较之mysqldump要快些。下面是两种方式备份同一个数据的 时候的时间消耗比较：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003emysqldump  耗时22分39秒（gzip 压缩后文件大小为747M.）\u003c/li\u003e\n\u003cli\u003emysqlhotcopy  耗时6分07秒（tar gzip打包压缩后文件大小为1014M.）\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e参考： …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2010/06/3455232156_dc09e11b22_o.jpg\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/3455232156_dc09e11b22_o.jpg\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://www.flickr.com/photos/26825745@N06/3455232156/\" title=\"replication by orczhou, on Flickr\"\u003ereplication by orczhou, on Flickr\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e在使用MySQL的应用中，如果你的MySQL Server压力逐渐增大，在应用层优化已经到了一定瓶颈时，那么你应该首先考虑 \u003ca href=\"http://dev.mysql.com/doc/refman/5.0/en/replication.html\"\u003eMySQL Replication\u003c/a\u003e。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e如何同步\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e主库将所有的更新操作，写入二进制日志。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e从库运行”IO线程”（Slave IO Thread）读取主库的二进制日志。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e从库运行”SQL线程”（Slave SQL Thread）执行IO线程（Slave IO Thread）读取的日志中的SQL,从而保持和主库的一致。\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003e如何分配请求\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e目前，这部分需要在应用层实现。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e执行更新SQL(UPDATE，INSERT，DELETE)时，请求主库。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e执行查询SQL(SELECT)时，请求从库。\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e所以，当你的应用(Application)SELECT请求所占的比率越大，那么Relication就会越有效。\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003eExplain ID详解\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e含义：select查询的序列号，是一组数字，表示的是查询中执行select子句或者是操作表的顺序。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eid的情况有三种，分别是：\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eid相同表示加载表的顺序是从上到下。\u003c/li\u003e\n\u003cli\u003eid不同id值越大，优先级越高，越先被执行。\u003c/li\u003e\n\u003cli\u003eid有相同，也有不同，同时存在。id相同的可以认为是一组，从上往下顺序执行；在所有的组中，id的值越大，优先级越高，越先执行。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e再看一个查询计划的例子：\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://blog.haohtml.com/wp-content/uploads/2010/06/mysql_explain.png\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/mysql_explain.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e执行顺序依次为 4 -\u0026gt; 3 -\u0026gt; 2 \u0026gt; 1 \u0026gt; NULL\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e第一行：id列为1，表示第一个select，select_type列的primary表示该查询为外层查询，table列被标记为，表示查询结果来自一个衍生表，其中3代表该查询衍生自第三个select查询，即id为3的select。[select d1.name……]\u003c/p\u003e\n\u003cp\u003e第二行：id为3，表示该查询的执行次序为2（4→3），是整个查询中第三个select的一部分。因查询包含在from中，所以为derived。[select id,name from t1 where other_column=”]\u003c/p\u003e\n\u003cp\u003e第三 …\u003c/p\u003e"

"\u003cp\u003emysqldump是非常重要的MySQL备份工具。然而在长年累月的使用过程中，TAOBAO多次出现了因mysqldump意外终止而导致备份 失败的情况。\n以下是我们经常遇到的问题：\u003c/p\u003e\n\u003cp\u003e1、Lost connection to MySQL server at ‘reading initial communication packet’：\n这个主要是因为DNS不稳定导致的。如果做了网络隔离，MySQL处于一个相对安全的网络环境，那么开启skip-name-resolve选项将会最大 程度避免这个问题。\u003c/p\u003e\n\u003cp\u003e2、Lost connection to MySQL server at ‘reading authorization packet’：\n从MySQL获取一个可用的连接是多次握手的结果。在多次握手的过程中，网络波动会导致握手失败。增加connect_timeout可以解决这个问题； 然而增加connect_timeout并不能防止网络故障的发生，反而会引起MySQL线程占用。最好的解决办法是让mysqldump重新发起连接请 求。\u003c/p\u003e\n\u003cp\u003e3、Lost connection to MySQL …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e“And God said, Let there be network: and there was timeout”\u003c/strong\u003e\n在使用MySQL的过程中，你是否遇到了众多让人百思不得其解的Timeout？\n那么这些Timeout之后，到底是代码问题，还是不为人知的匠心独具？\n本期Out-man，讲述咱们MySQL DBA自己的Timeout。\u003c/p\u003e\n\u003cp\u003e先看一下比较常见的Timeout参数和相关解释：\n\u003cstrong\u003econnect_timeout\u003c/strong\u003e\nThe number of seconds that the mysqld server waits for a connect packet before responding with Bad handshake.\n\u003cstrong\u003einteractive_timeout\u003c/strong\u003e\nThe number of seconds the server waits for activity on an interactive connection before closing it.\n\u003cstrong\u003ewait_timeout\u003c/strong\u003e\nThe number of seconds the server waits for …\u003c/p\u003e"

"\u003cp\u003e在经历了2009年的分布式启步之后，经过改造的数据库系统性能得到极大的提升，但这个变化仍然不构成今天这篇文章的主题，我想要说的是另外一方面的变 化，这个变化在某种程度上影响着当前DBA的角色变化问题。\u003c/p\u003e\n\u003cp\u003e在分布式数据库时代，开发DBA的开发支持工作相比于以前，会有更多的系统思考问题的机会，会结合应用来设计量身定做的分布式数据库系统，如果一个DBA 对业务有着深刻的理解，深刻理解数据库原理，既具有整体性的架构思维，又有一些关键细节把握能力的时候，设计一套分布式系统是水到渠成的事。对于开发支持 的一些工作，比如SQL审核，表结构变更，数据订正，历史迁移，如果没有工具的支持，那做起来还是比较吃力的。这些方面，我们还有许多的道路要走，怎么样 改变目前的现状。\u003c/p\u003e\n\u003cp\u003e在分布式数据库时代，系统DBA的运维要求难度在某方面有所降低，整个应用因为在容错性方面做了比较多的努力，比如down掉一个数据库时，对于整个应用 系统的健康运行影响较小,运维的压力相对减少。相比于集中式的数据库环境下的运维，在另外一个层面运维难度又有所增加，第一，运维的机器数量呈几何指数的 增长，由于大量采用低端机器，集群中某个机器出问题的 …\u003c/p\u003e"

"\u003cp\u003e本文将讲述MySQL中多种存储引擎的特点，希望可以给你在选择 MySQL存储引擎时带来帮助。\u003c/p\u003e\n\u003cp\u003eMySQL有多种存储引擎：\u003c/p\u003e\n\u003cp\u003eMyISAM、InnoDB、MERGE、MEMORY(HEAP)、BDB(BerkeleyDB)、EXAMPLE、FEDERATED、 ARCHIVE、CSV、BLACKHOLE。\u003c/p\u003e\n\u003cp\u003eMySQL支持数个存储引擎作为对不同表的类型的处理器。MySQL存储引擎包括处理事务安全表的引擎和处理非事务安全表的引擎：\u003c/p\u003e\n\u003cp\u003e◆ MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。MyISAM在所有MySQL配置里被支持，它是默认的存储引擎，除非你配置 MySQL默认使用另外一个引擎。\u003c/p\u003e\n\u003cp\u003e◆ MEMORY存储引擎提供“内存中”表。MERGE存储引擎允许集合将被处理同样的MyISAM表作为一个单独的表。就像MyISAM一样，MEMORY 和MERGE存储引擎处理非事务表，这两个引擎也都被默认包含在MySQL中。\u003c/p\u003e\n\u003cp\u003e注释：MEMORY存储引擎正式地被确定为HEAP引擎。\u003c/p\u003e\n\u003cp\u003e◆ InnoDB和BDB存储引擎提供事务安全表。BDB被包含在为支持它的操作系统发布的MySQL-Max二进制分 …\u003c/p\u003e"

"\u003cp\u003eMySQL Cluster是MySQL适合于分布式计算环境的高实用、高冗余版本。它采用了NDB Cluster存储引擎，允许在1个Cluster中运行多个MySQL服务器。\u003c/p\u003e\n\u003cp\u003eMySQL Cluster是一种技术，该技术允许在无共享的系统中部署“内存中”数据库的Cluster。通过无共享体系结构，系统能够使用廉价的硬件，而且对软硬 件无特殊要求。此外，由于每个组件有自己的内存和磁盘，不存在单点故障。\u003c/p\u003e\n\u003cp\u003e总结了些移植到MySQL Cluster要注意的常见问题。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e关于连接\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eMySQL集群适合用于高速带宽的环境中，采用TCP/IP方式 连接。它的性能跟主机间的连接速率有直接关系。集群中的最小速率要求是常规的100Mb以太网或者等同的网络。我们建议可能的话就采用G级网络。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e关于内存\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eMySQL集群可以运行在任何启用NDB的平台上。显然，CPU 越快，内存越大，对集群性能提升越明显，64位的CPU也可能比32位的处理器更快。每个作为数据节点的机器都必须有足够的内存来保存共享数据库。\u003c/p\u003e\n\u003cp\u003e在MySQL 5.0中，集群只能基于内存。意思是所有表的数据(包括索引)都保存在内存中。如果你的数据有1GB那么大， …\u003c/p\u003e"

"\u003cp\u003e我们今天主要向大家介绍的是MySQL 集群，其中包括对MySQL 集群的概念介绍，以及如何在Server1与Server2上正确对MySQL进行安装 ，还有对安装与配置管理节点服务器(Server3)的正确操作 ，配置集群服务器并启动MySQL 。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一、介绍\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e这篇文档旨在介绍如何安装配置基于2台服务器的MySQL集群。并且实现任意一台服务器出现问题或宕机时MySQL依然能够继续运行。\u003c/p\u003e\n\u003cp\u003e注意！\u003c/p\u003e\n\u003cp\u003e虽然这是基于2台服务器的MySQL集群，但也必须有额外的第三台服务器作为管理节点，但这台服务器可以在集群启动完成后关闭。同时需要注意的是并 不推荐在集群启动完成后关闭作为管理节点的服务器。尽管理论上可以建立基于只有2台服务器的MySQL集群，但是这样的架构，一旦一台服务器宕机之后集群 就无法继续正常工作了，这样也就失去了集群的意义了。出于这个原因，就需要有第三台服务器作为管理节点运行。\u003c/p\u003e\n\u003cp\u003e另外，可能很多朋友都没有3台服务器的实际环境，可以考虑在VMWare或其他虚拟机中进行实验。\u003c/p\u003e\n\u003cp\u003e下面假设这3台服务的情况：\u003c/p\u003e\n\u003cp\u003eServer1: MySQL1.vmtest.net 192.168.0.1 …\u003c/p\u003e"

"\u003cp\u003e1．  先了解一下你是否应该用 mysql 集群。\u003c/p\u003e\n\u003cp\u003e减少数据中心结点压力和大数据量处理，采用把 mysql 分布，一个或多个 application 对应一个 mysql 数据库。把几个 mysql 数据库公用的数据做出共享数据，例如购物车，用户对象等等，存在数据结点里面。 其他不共享的数据还维持在各自分布的 mysql 数据库本身中。\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2010/06/cluster-components-1.png\"\u003e\u003cimg src=\"http://blog.haohtml.com/wp-content/uploads/2010/06/cluster-components-1.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e2．  集群 Mysql 中名称概念 .( 如上图 )\u003c/p\u003e\n\u003cp\u003e1 ） Sql 结点（ SQL node– 上图对应为 mysqld ） : 分布式数据库。包括自身数据和查询中心结点数据 .\u003c/p\u003e\n\u003cp\u003e2 ）数据结点 (Data node — ndbd): 集群共享数据 ( 内存中 ).\u003c/p\u003e\n\u003cp\u003e3 ）管理服务器 (Management Server – ndb_mgmd): 集群管理 SQL node,Data node.\u003c/p\u003e\n\u003cp\u003e3 ．配置\u003c/p\u003e\n\u003cp\u003emysql-max 版本，当然现在 mysql 集群系统 windonws 平台上面不被支持 .\u003c/p\u003e\n\u003cp\u003e安装 mysql 就不多说了，网上一打堆，简明扼要。\u003c/p\u003e\n\u003cp\u003eA:192.168.1.251 – Data node 和 Management …\u003c/p\u003e"

"\u003cp\u003e在为某证券公司设计其OA架构时，初期客户是30万用户在线；然而在项目实施中，客户又提出50万用户同时在线的需求，而且都有写的需求；这样初始的设计 master-master-slave，读写分离满足不了客户的要求，所以我们打算采用Mysql Cluster方案；MySQL Cluster 是MySQL适合于分布式计算环境的高实用、高冗余版本。它采用了NDB Cluster 存储引擎，允许在1个Cluster中运行多个MySQL服务器。在MyQL 5.0及以上的二进制版本中、以及与最新的Linux版本兼容的RPM中提供了该存储引擎。\u003c/p\u003e\n\u003cp\u003e一、MySQL Cluster概述\u003c/p\u003e\n\u003cp\u003eMySQL Cluster 是一种技术，该技术允许在无共享的系统中部署“内存中”数据库的 Cluster 。通过无共享体系结构，系统能够使用廉价的硬件，而且对软硬件无特殊要求。此外，由于每个组件有自己的内存和磁盘，不存在单点故障。\u003c/p\u003e\n\u003cp\u003eMySQL Cluster 由一组计算机构成，每台计算机上均运行着多种进程，包括MySQL服务器，NDB Cluster 的数据节点，管理服务器，以及（可能）专门的数据访问程序。\u003c/p\u003e\n\u003cp\u003e所有的这些节点 …\u003c/p\u003e"

"\u003cp\u003e如果用户想改变表的默认字符集和所有的字符列的字符集到一个新的字符集，使用下面的语句：\nALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name;\u003c/p\u003e\n\u003cp\u003e警告：\n上述操作是在字符集中转换列值。如果 用户在字符集（如 gb2312）中有一个列，但存储的值使用的是其它的一些不兼容的字符集（如 utf8），那么该操作将不会得到用户期望的结果。在这种情况下，用户必须对每一列做如下操作：\u003c/p\u003e\n\u003cp\u003eALTER TABLE t1 CHANGE c1 c1 BLOB;\nALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET utf8;\u003c/p\u003e\n\u003cp\u003e这样做的原因是：从 BLOB 列转换或转换到 BLOB 列没有转换发生。\u003c/p\u003e\n\u003cp\u003e如果用户指定以二进制进行 CONVERT TO CHARACTER SET，则 CHAR、VARCHAR 和 TEXT 列将转换为它们对应的二进制字符串类型（BINARY，VARBINARY，BLOB）。这意味着这些列将不再有字符集，随后的 CONVERT TO 操作也将不会作用到它们上。\u003c/p\u003e\n\u003cp\u003e如果仅仅改变一个表的缺省字 …\u003c/p\u003e"

"\u003cp\u003eInnoDB和MyISAM是在使用MySQL最常用的两个表类型，各有优缺点，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等 高级处 理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已 经外部键等高级数据库功能。\u003c/p\u003e\n\u003cp\u003eMyIASM是IASM表的新版本，有如下扩展：\u003c/p\u003e\n\u003cp\u003e1、二进制层次的可移植性。\u003c/p\u003e\n\u003cp\u003e2、NULL列索引。\u003c/p\u003e\n\u003cp\u003e3、对变长行比ISAM表有更少的碎片。\u003c/p\u003e\n\u003cp\u003e4、支持大文件。\u003c/p\u003e\n\u003cp\u003e5、更好的索引压缩。\u003c/p\u003e\n\u003cp\u003e6、更好的键码统计分布。\u003c/p\u003e\n\u003cp\u003e7、更好和更快的auto_increment处理。\u003c/p\u003e\n\u003cp\u003eInnoDB 是 MySQL 上第一个提供外键约束的引擎，除了提供事务处理外，InnoDB 还支持行锁，提供和 Oracle 一样的一致性的不加锁读取，能增加并发读的用户数量并提高性能，不会增加锁的数量。\u003c/p\u003e\n\u003cp\u003eInnoDB 的设计目标是处理大容量数据时最大化性能，它的 CPU 利用率是其他所有基于磁盘的关系数据库引擎中最有效率的。\u003c/p\u003e\n\u003cp\u003eInnoDB 是一套放在 MySQL 后台的完整数据库系统，InnoDB 有它自己的缓冲池， …\u003c/p\u003e"

"\u003cp\u003e假设有一个表，结构如下：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql\u0026gt; CREATE TABLE `a` (\n `id` int(10) unsigned NOT NULL AUTO_INCREMENT,\n `id2` int(10) unsigned NOT NULL DEFAULT \u0026#39;0\u0026#39;,\n PRIMARY KEY (`id`)\n) ENGINE=MyISAM;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e该表中只有6条记录，如下：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql\u0026gt; select * from a;\n+----+---------+\n| id | city_id |\n+----+---------+\n| 2 | 2 |\n| 3 | 3 |\n| 5 | 5 |\n| 4 | 4 |\n| 6 | 6 |\n| 7 | 7 |\n+----+---------+\n注意上面id的显示顺序，由于没有指定排序字段，myisam表引擎是随机显示记录列表的。\n现在想要把id字段分别-1，执行以下语句，得到报错：\n\u003c/code\u003e\u003c/pre\u003e\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql\u0026gt; update a set id=id-1; …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e\u003cstrong\u003e– 备份\u003c/strong\u003e\nmysqldump –force –quick –skip-opt –create-options –add-drop-table –extended-insert –host=”localhost” –user=”root” –password=”密码” “数据库名称” \u0026gt; C:/2010-01-26.sql\n**\n– 还原**\nmysql –host=”localhost” –user=”root” –password=”密码” “数据库名称” \u0026lt; C:/2010-01-26.sql\u003c/p\u003e\n\u003cp\u003e本文总结了MySQL数据库备份及恢复常用命令mysqldump,source的用法。\n还原一个数据库:mysql -h localhost -u root -p123456 www\u003c/p\u003e\n\u003cp\u003e备份一个数据库:mysqldump -h localhost -u root -p123456 www \u0026gt; d:\\www2008-2-26.sql\u003c/p\u003e\n\u003cp\u003e//以下是在程序中进行测试\u003c/p\u003e\n\u003cp\u003e//$command = “mysqldump –opt -h $dbhost -u $dbuser -p …\u003c/p\u003e"

"\u003cp\u003emysql查 看表结构命令，如下:\u003c/p\u003e\n\u003cp\u003edesc 表名;\u003c/p\u003e\n\u003cp\u003eshow columns from 表名;\u003c/p\u003e\n\u003cp\u003edescribe 表名;\u003c/p\u003e\n\u003cp\u003eshow create table 表名;\u003c/p\u003e\n\u003cp\u003euse information_schema\u003c/p\u003e\n\u003cp\u003eselect * from columns where table_name=’表名’;\u003c/p\u003e\n\u003cp\u003e顺便记下：\u003c/p\u003e\n\u003cp\u003eshow databases;\u003c/p\u003e\n\u003cp\u003euse 数据库名;\u003c/p\u003e\n\u003cp\u003eshow tables;\u003c/p\u003e\n\u003cp\u003e原有一unique索引AK_PAS_Name(PAC_Name)在表 tb_webparamcounter中，\u003c/p\u003e\n\u003cp\u003e执行以下sql修改索引\u003c/p\u003e\n\u003cp\u003ealter table tb_webparamcounter drop index AK_PAS_Name;\u003c/p\u003e\n\u003cp\u003ealter table tb_webparamcounter add UNIQUE AK_PAS_Name(PC_ID,PAC_Name);\u003c/p\u003e\n\u003cp\u003e若发现索引的逻辑不对，还需要再加一个字段进去，执行\u003c/p\u003e\n\u003cp\u003ealter table tb_webparamcounter drop index AK_PAS_Name;\u003c/p\u003e\n\u003cp\u003ealter table …\u003c/p\u003e"

"\u003cp\u003eupdate table_all a set a.phoneNo=b.phoneNo from table_new b where a.name =b.name\u003c/p\u003e\n\u003cp\u003eupdate table_all set table_all.phoneNo = (select table_new.phoneNo from table_new where table_all.name = table_new.name)\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e比较IN()里面的数据\u003c/strong\u003e\n许多数据库服务器都只把IN()看作多个OR的同义词，因为它们在逻辑上是相等的。MYSQL不是这样的，它会对IN()里面的数据进行排序，然后用二分法查找个是否在列表中，这个算法的效率是Ｏ（Ｌogn),而等同的OR子句的查找效率是Ｏ(n)。在列表很大的时候，OR子句就会变得慢得多。\u003c/p\u003e\n\u003cp\u003e这里的语句和Oracle数据库里是一样的。\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003eQ\u003c/strong\u003e：我怎样强制主服务器阻塞更新直到从服务器同步？\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eA\u003c/strong\u003e：使用下面的步骤：\u003c/p\u003e\n\u003cp\u003e1.在主服务器上，执行这些语句：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql\u0026gt; FLUSH TABLES WITH READ LOCK;\n\u003c/code\u003e\u003c/pre\u003e\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql\u0026gt; SHOW MASTER STATUS;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e记录SHOW语句的输出的日志名和偏移量。这些是复制坐标。2.在从服务器上，发出下面的语句，其中Master_POS_WAIT()函 数的参量是前面步骤中的得到的复制坐标值：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql\u0026gt; SELECT MASTER_POS_WAIT(\u0026#39;log_name\u0026#39;, log_offset);\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eSELECT语句阻塞直到从服务器达到指定的日志文件和偏移量。此时，从服务器与主服务器同步，语句返回。\u003c/p\u003e\n\u003cp\u003e3.在主服务器上，发出下面的语句允许主服务器重新开始处理更新：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql\u0026gt; UNLOCK TABLES；\n\n来源:http://dev.mysql.com/doc/refman/5.1/zh/replication.html#replication-faq\n\u003c/code\u003e\u003c/pre\u003e"

"\u003ch3 id=\"634复制传递和状态文件\"\u003e6.3.4. 复制传递和状态文件\u003c/h3\u003e\n\u003cp\u003e默认情况，中继日志使用_host_name-relay-bin.nnnnnn_形 式的文件名，其中_host_name_是从服务器主机名，\u003cem\u003ennnnnn_是 序列号。用连续序列号来创建连续中继日志文件，从000001开始。从服务器跟踪索引文件中目前正 使用的中继日志。 默认中继日志索引文件名为_host_name-relay-bin.index\u003c/em\u003e。 默认情况，在从服务器的数据目录中创建这些文件。可以用–relay-log和–relay-log-index服 务器选项覆盖 默认文件名。参见\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/replication.html#replication-options\" title=\"6.8. Replication Startup Options\"\u003e6.8节，“复制启动选项”\u003c/a\u003e。\u003c/p\u003e\n\u003cp\u003e中继日志与二进制日志的格式相同，并且可以用\u003cstrong\u003emysqlbinlog\u003c/strong\u003e读取。SQL线 程执行完中继日志中的所有事件并且不再需要之后，立即自动删除它。没有直接的删除中继日志的机制，因为SQL线程可以负责完 成。然而，FLUSH LOGS可以循环中继日志，当SQL线程删除日志时会有影响。\u003c/p\u003e\n\u003cp\u003e在下面的条件下创建新的中继日志：\u003c/p\u003e\n\u003cp\u003e·每次I/O线程启动时创建一个新的中继日志。\u003c/p\u003e\n\u003cp\u003e·当日志被刷新时；例如，用FLUSH LOGS或\u003cstrong\u003emysqladmin …\u003c/strong\u003e\u003c/p\u003e"

"\u003cp\u003e用EXPLAIN看MySQL的执行计划时经常会看到Impossible WHERE noticed after reading const tables这句话，意思是说MySQL通过读取“const tables”，发现这个查询是不可能有结果输出的。比如对下面的表和数据：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e create table t (a int primary key, b int) engine = innodb;\n insert into t values(1, 1);\n insert into t values(3, 1);\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e执 行“EXPLAIN select * from t where a = 2”时就会输出“Impossible WHERE noticed after reading const tables”。\u003c/p\u003e\n\u003cp\u003e不明白所谓的“const tables”是什么意思，对MySQL在查询优化时竟然可以发现一个查询不可能输出结果更是感觉不可思议。按数据库中“传统”的做法，查询优化时只会访问模式定义和统计信息，而据我所知，数据库中使用的各种统计信息如EquiDepth、MaxDiff柱状图，MCV，属性的最 …\u003c/p\u003e"

"\u003cp\u003e译者：叶金荣（Email:\u003cimg src=\"http://imysql.cn/files/pictures/email.gif\" alt=\"\"\u003e），来源：MySQL手册版 本 5.0.20，转载请注明译者和出处，并且不能用于商业用途，违者必究。\u003c/p\u003e\n\u003ch4 id=\"145316\"\u003e\u003ca href=\"javascript:void(0);\"\u003e14.5.3.16 \u003ccode\u003eSHOW PROCESSLIST\u003c/code\u003e 语法\u003c/a\u003e\u003c/h4\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eSHOW [FULL] PROCESSLIST\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e\u003ccode\u003eSHOW PROCESSLIST\u003c/code\u003e 显示了有哪些线程在运行。也可以执行 \u003ccode\u003emysqladmin processlist\u003c/code\u003e 命令来得到这些信息。如果有 \u003ccode\u003eSUPER\u003c/code\u003e 权限，则可以看到全部的线程，否则，只能看到自己发起的线程（这是指，当前对应的MySQL帐户运行的线程）。详情请看“\u003ca href=\"javascript:void(0);\"\u003e14.5.4.3 \u003ccode\u003eKILL\u003c/code\u003e Syntax\u003c/a\u003e”。如果没有使用 关键字 \u003ccode\u003eFULL\u003c/code\u003e，则只能看到每个查询的前100个字符。\u003c/p\u003e\n\u003cp\u003e从MySQL 4.0.12起，结果中还会以的 \u003ccode\u003ehost_name:client_port\u003c/code\u003e 格式来显示通过TCP/IP方式连接过来的客户端的主机名，这就可以知道每个客户端都正在做什么。\u003c/p\u003e\n\u003cp\u003e这个语句在出现“too many connections”错误时想看看都正在执行什么查询非常有用。MySQL为拥有 \u003ccode\u003eSUPER\u003c/code\u003e 权限的账户保留了一个额外的连接，这就保证让管理员总是可以连上检查系 …\u003c/p\u003e"

"\u003cp\u003e表分区为海量数据的存储提供了一种更有效率的储存方式，可通过分区将表的数据分开存储在不同的磁盘上，提高数据检索和操作的效率。\u003c/p\u003e\n\u003cp\u003e在SQL Server中进行表分区操作，包括三个步骤：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e创建分区函数\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eCREATE PARTITION FUNCTION \u003ca href=\"datetime\"\u003eFN_Partition\u003c/a\u003e AS RANGE LEFT FOR VALUES (N’2008-01-01T23:59:59′, N’2009-01-01T23:59:59′, N’2010-01-01T23:59:59′)\u003c/p\u003e\n\u003cp\u003e此分区函数采用时间进行分区，共有4个分区，边界值为括号里的时间值\u003c/p\u003e\n\u003cp\u003e第一个分区为: 时间 第二个分区为: N’2008-01-01T23:59:59′\u0026lt;  时间 第三个分区为: N’2009-01-01T23:59:59′\u0026lt; 时间 第四个分区为: 时间\u0026gt;N’2010-01-01T23:59:59′\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e创建分区方案\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eCREATE PARTITION SCHEME [SE_Partition] AS PARTITION [FN_Partition] TO ([xmsddgroup1], …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e1. 语法：命名规则\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eCREATE TRIGGER \u0026lt;触发器名称\u0026gt; \u0026lt;–\n{ BEFORE | AFTER }\n{ INSERT | UPDATE | DELETE }\nON \u0026lt;表名称\u0026gt;\nFOR EACH ROW\n\u0026lt;触发器SQL语句\u0026gt;\u003c/p\u003e\n\u003cp\u003e触发器必须有名字，最多64个字符，可能后面会附有分隔符.它和MySQL中其他对象的命名方式基本相象.\u003c/p\u003e\n\u003cp\u003e这里我有个习惯：就是用表的名字＋’_’＋触发器类型的缩写.因此如果是表t26，触发器是在事件UPDATE（参考下面的点（2）和（3））之前 （BEFORE）的，那么它的名字就是t26_bu。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e2. 语法：触发时间\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eCREATE TRIGGER \u0026lt;触发器名称\u0026gt;\n{ BEFORE | AFTER } \u0026lt;–\n{ INSERT | UPDATE | DELETE }\nON \u0026lt;表名称\u0026gt;\nFOR EACH ROW\n\u0026lt;触发的SQL语句\u0026gt;\u003c/p\u003e\n\u003cp\u003e触发器有执行的时间设置：可以设置为事件发生前或后 BEFORE | AFTER 。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3. 语法：事件\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eCREATE TRIGGER \u0026lt;触发器名 …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e简介：\u003c/strong\u003e 一个存储过程包括名字，参数列表，以及可以包括很多SQL语句的SQL语句集。\u003c/p\u003e\n\u003cp\u003e一个存储过程包括名字，参数列表，以及可以包括很多SQL语句的SQL语句集。\u003c/p\u003e\n\u003cp\u003e创建存储 过程：\u003c/p\u003e\n\u003cp\u003e语法：\u003c/p\u003e\n\u003cp\u003eCREATE PROCEDURE p()\u003c/p\u003e\n\u003cp\u003eBEGIN\u003c/p\u003e\n\u003cp\u003e/\u003cem\u003e此存储过程的正文\u003c/em\u003e/\u003c/p\u003e\n\u003cp\u003eEND\u003c/p\u003e\n\u003cp\u003eCREATE PROCEDURE productpricing()\u003c/p\u003e\n\u003cp\u003eBEGIN\u003c/p\u003e\n\u003cp\u003eSELECT Avg(pro_price) AS priceaverage\u003c/p\u003e\n\u003cp\u003eFROMproducts;\u003c/p\u003e\n\u003cp\u003eEND;\u003c/p\u003e\n\u003ch1 id=\"beginend之间是存储过程的主体定义\"\u003ebegin…end之间是存储过程的主体定义\u003c/h1\u003e\n\u003ch1 id=\"mysql的分界符是分号\"\u003emysql的分界符是分号（；）\u003c/h1\u003e\n\u003cp\u003e调用存储 过程的方法是：\u003c/p\u003e\n\u003ch1 id=\"call加上过程名以及一个括号\"\u003eCALL加上过程名以及一个括号\u003c/h1\u003e\n\u003ch1 id=\"例-如调用上面定义的存储过程\"\u003e例 如调用上面定义的存储过程\u003c/h1\u003e\n\u003cp\u003eCALL productpricing();\u003c/p\u003e\n\u003ch1 id=\"哪-怕是不用传递参数存储过程名字后面的括号也是必须的\"\u003e哪 怕是不用传递参数，存储过程名字后面的括号“（）”也是必须的\u003c/h1\u003e\n\u003cp\u003e删除存储 过程的方法是：\u003c/p\u003e\n\u003cp\u003eDROP PROCUDURE productpricing;\u003c/p\u003e\n\u003cp\u003e创建带参 数的存储过程：\u003c/p\u003e\n\u003cp\u003eCREATE PROCUDURE productpricing(\u003c/p\u003e\n\u003cp\u003eOUT p1 DECIMAL(8,2),\u003c/p\u003e\n\u003cp\u003eOUT ph DECIMAL(8,2), …\u003c/p\u003e"

"\u003cp\u003e在mysql中，大多数索引（如 PRIMARY KEY,UNIQUE,INDEX和FULLTEXT）都是在BTREE中存储，但使用memory引擎可以选择BTREE索引或者HASH索引，两种不同类型的索引各自有其不同的使用范围。\u003c/p\u003e\n\u003cp\u003eHash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。\u003c/p\u003e\n\u003cp\u003e可能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢？任何事物都是有两面性的，Hash 索引也一样，虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。\u003c/p\u003e\n\u003cp\u003e（1）Hash 索引仅仅能满足”=”,”IN”和”\u0026lt;=\u0026gt;”查询，不能使用范围查询。\u003c/p\u003e\n\u003cp\u003e由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash …\u003c/p\u003e"

"\u003cp\u003e自己经常使用sqlserver,不怎么使用mysql.所以也对mysql不咋米了解。这里转两个帖子关于mysql中的InnoDB和MyIsAM的介绍，个人觉得还是不错的。\u003c/p\u003e\n\u003cp\u003e转载自 \u003ca href=\"http://database.51cto.com/\"\u003ehttp://database.51cto.com\u003c/a\u003e 2009-05-19 09:58  邵宗文  IT168\u003c/p\u003e\n\u003cp\u003e链接：http://database.51cto.com/art/200905/122382.htm\u003c/p\u003e\n\u003ch3 id=\"浅谈mysql存储引擎选择-innodb还是myisam\"\u003e浅谈MySQL存储引擎选择 InnoDB还是MyISAM\u003c/h3\u003e\n\u003cp\u003eMyISAM 是MySQL中默认的存储引擎，一般来说不是有太多人关心这个东西。决定使用什么样的存储引擎是一个很tricky的事情，但是还是值我们去研究一下，这 里的文章只考虑 MyISAM 和InnoDB这两个，因为这两个是最常见的。\u003c/p\u003e\n\u003cp\u003e下面先让我们回答一些问题：\u003c/p\u003e\n\u003cp\u003e◆你的数据库有外键吗？\u003c/p\u003e\n\u003cp\u003e◆你需要事务支持吗？\u003c/p\u003e\n\u003cp\u003e◆你需要全文索引吗？\u003c/p\u003e\n\u003cp\u003e◆你经常使用 什么样的查询模式？\u003c/p\u003e\n\u003cp\u003e◆你的数据有多大？\u003c/p\u003e\n\u003cp\u003e思考上面这些问题可以让你找到合适的方向，但那并不是绝对的。如果你需要事务处理或是外键，那么InnoDB 可能是比较好的方式。如果你需要全文索引， …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003emysql忘记root 密码如何处理?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e如果 MySQL 正在运行，首先结束mysql进程： killall mysqld\u003c/p\u003e\n\u003cp\u003e启动 MySQL (非正常方式起动)：/usr/local/mysql/bin/mysqld_safe –-skip-grant-tables \u0026amp;\u003c/p\u003e\n\u003cp\u003e这样就可以不需要密码进入 MySQL ：/usr/local/mysql/bin/mysql -u root -p　（要求输入密码时直接回车即可）\u003c/p\u003e\n\u003cp\u003emysql\u0026gt; update user mysql.set password=password(”新密码”) where user=”root”;\u003c/p\u003e\n\u003cp\u003emysql\u0026gt; flush privileges;\u003c/p\u003e\n\u003cp\u003emysql\u0026gt; quit;\u003c/p\u003e\n\u003cp\u003e重新结束进程：killall mysqld\u003c/p\u003e\n\u003cp\u003e用正常方式启动 MySQL ：/usr/local/mysql/bin/mysqld_safe -user=mysql \u0026amp;\u003c/p\u003e"

"\u003cp\u003e2008年4月18日，在Alexa安排的一次“ \u003ca href=\"http://venublog.com/2008/04/16/notes-from-scaling-mysql-up-or-out/\"\u003eScaling MySQL — Up or Out?\u003c/a\u003e”的小组辩论中，MySQL、Sun、 Flickr、Fotolog、Wkipedia、Facebook、YouTube等国际知名网站的DBA们，对其网站MySQL数据库服务器、Web 服务器、缓存服务器的数量，MySQL版本，编程语言类型，操作系统类型等问题进行了回答。 \u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2010/04/mysql_number.gif\"\u003e\u003cimg src=\"http://blog.haohtml.com/wp-content/uploads/2010/04/mysql_number.gif\" alt=\"mysql_number\"\u003e\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003e[文章作者：张宴 本文版本：v1.1 最后修改：2008.09.09 转载请注明原文链接： \u003ca href=\"http://blog.s135.com/post/357/\"\u003ehttp://blog.s135.com/post/357/\u003c/a\u003e]\u003c/p\u003e\n\u003cp\u003e鉴于国内外还没有人撰写如何安装Memcache_engine的文章，于是，我根据自己的编译安装步骤，写下此文。\u003c/p\u003e\n\u003cp\u003eMemcache_engine是一个MySQL 5.1数据库的存储引擎，它能够让用户通过标准的SQL语句（SELECT/UPDATE/INSERTE/DELETE）访问Memcached（还支 持新浪的 \u003ca href=\"http://www.memcachedb.org/\"\u003eMemcachedb\u003c/a\u003e、 \u003ca href=\"http://code.google.com/p/dbcached\"\u003edbcached\u003c/a\u003e）中 存放的数据。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e限制：\u003c/strong\u003e\n1、Memcache表必须有主键。\n2、只能使用主 键去查询，即只能使用SELECT … FROM … WHERE id = … 方式去查询。\n3、不支持自增ID。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e安装与使用：\u003c/strong\u003e\n1、编译安装memcache_engine的步骤：\u003c/p\u003e\n\u003cp\u003ecd /tmp\u003c/p\u003e\n\u003cp\u003ewget …\u003c/p\u003e"

"\u003cp\u003e使用Xdebug调试和优化PHP程序系列教程之WinCacheGrind，教你如何利用Xdebug 配合WinCacheGrind工具来检测PHP代码的效率以及分析PHP代码。\u003c/p\u003e\n\u003cp\u003e另外还有一个结果分析展示工具webgrind。可参考： \u003ca href=\"http://blog.sina.com.cn/s/blog_635833b3010127q5.html\"\u003ehttp://blog.sina.com.cn/s/blog_635833b3010127q5.html\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e有时候代码没有明显的编写错误，没有显示任何错误信息（如 error、warning、notice等），但是这不表明代码就是正确无误的。有时候可能某段代码执行时间过长，占用内存过多以致于影响整个系统的效 率，我们没有办法直接看出来是哪部份代码出了问题。这时候我们希望把代码的每个阶段的运行情况都监控起来，写到日志文件中去，运行一段时间后再进行分析， 找到问题所在。\u003c/p\u003e\n\u003cp\u003e回忆一下，之前我们编辑php.ini文件\n加入\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003e[Xdebug]\u0026lt;br /\u0026gt; xdebug.profiler_enable=on\u0026lt;br /\u0026gt; xdebug.trace_output_dir=\u0026quot;I:\\Projects\\xdebug\u0026quot;\u0026lt;br …\u003c/code\u003e\u003c/p\u003e"

"\u003cp\u003e查看 MySQL 語法 詳細執行時間 與 CPU/記憶體使用量: MySQL Query Profiler\u003c/p\u003e\n\u003cp\u003eMySQL 的 SQL 語法調整主要都是使用 \u003ca href=\"http://dev.mysql.com/doc/refman/5.0/en/explain.html\" title=\"MySQL :: MySQL 5.0 Reference Manual :: 12.3.2 EXPLAIN Syntax\"\u003eEXPLAIN\u003c/a\u003e , 但是這個並沒辦法知道詳細的 Ram(Memory)/CPU 等使用量.\u003c/p\u003e\n\u003cp\u003e於 MySQL 5.0.37 以上開始支援 MySQL Query Profiler, 可以查詢到此 SQL 會執行多少時間, 並看出 CPU/Memory 使用量, 執行過程中 System lock, Table lock 花多少時間等等.\u003c/p\u003e\n\u003cp\u003eMySQL Query Profile 詳細介紹可見: \u003ca href=\"http://dev.mysql.com/tech-resources/articles/using-new-query-profiler.html\" title=\"Using the New MySQL Query Profiler\"\u003eUsing the New MySQL Query Profiler\u003c/a\u003e (2007.04.05 發表)\u003c/p\u003e\n\u003cp\u003e效能分析主要分下述三種(轉載自上篇):\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eBottleneck analysis – focuses on answering the questions: What is my database server waiting on; what is a user connection waiting on; what is a piece of …\u003c/li\u003e\u003c/ul\u003e"

"\u003cp\u003e显然，我之前那个数据库备份程序太菜鸟了。还用select count(*) 来判断数据库的记录集数，其实完全不用那么麻烦。有一个简单的MML语句今天被我无意间发 现，”SHOW TABLE STATUS FROM `dbname`”，执行后会生成一个记录集。\u003c/p\u003e\n\u003cp\u003e记录集包含下列字段：\u003c/p\u003e\n\u003cp\u003eName: \u003cstrong\u003enewdb\u003c/strong\u003e （表名）\nEngine: \u003cstrong\u003eMyISAM\u003c/strong\u003e （表引擎）\nVersion: \u003cstrong\u003e10\u003c/strong\u003e （版本）\nRow_format: \u003cstrong\u003eDynamic\u003c/strong\u003e （行格式）\u003c/p\u003e\n\u003cp\u003eRows: \u003cstrong\u003e56496\u003c/strong\u003e （表内总行数）\n对于其它存储引擎，比如InnoDB，本值是一个大约的数，与实际值相差可达40到50％。 在这些情况下，使用SELECT COUNT(*)来获得准确的数目。对于在INFORMATION_SCHEMA数 据库中的表，Rows值为NULL\u003c/p\u003e\n\u003cp\u003eAvg_row_length: \u003cstrong\u003e4749\u003c/strong\u003e （平均每行大小，这里是4.7K）\nData_length: \u003cstrong\u003e268352680\u003c/strong\u003e （该表总大小，单位字节）\nMax_data_length: \u003cstrong\u003e281474976710655\u003c/strong\u003e （该表可存储上限，这个值所有表都一样，换算出来是256TB，应该用不 …\u003c/p\u003e"

"\u003cp\u003e今天在家里做了一下试验，终于搞明白了以前做复制的时候没有搞明白的问题。原来BINLOG就是一个记录SQL语句的过程，和普通的LOG一样。不过只是她是二进制存储，普通的是十进制存储罢了。\n1、配置文件里要写的东西：\n[mysqld]\nlog-bin=yueliangdao_binglog(名字可以改成自己的，如果不改名字的话，默认是以主机名字命名)重新启动MSYQL服务。\u003c/p\u003e\n\u003cp\u003e二进制文件里面的东西显示的就是执行所有语句的详细记录，当然一些语句不被记录在内，要了解详细的，见手册页。2、查看自己的BINLOG的名字是什么。\nshow binlog events;\u003c/p\u003e\n\u003ch3 id=\"query-result1-records\"\u003equery result(1 records)\u003c/h3\u003e\n\u003cp\u003eLog_name\u003c/p\u003e\n\u003cp\u003ePos\u003c/p\u003e\n\u003cp\u003eEvent_type\u003c/p\u003e\n\u003cp\u003eServer_id\u003c/p\u003e\n\u003cp\u003eEnd_log_pos\u003c/p\u003e\n\u003cp\u003eInfo\u003c/p\u003e\n\u003cp\u003eyueliangdao_binglog.000001\u003c/p\u003e\n\u003cp\u003e4\u003c/p\u003e\n\u003cp\u003eFormat_desc\u003c/p\u003e\n\u003cp\u003e1\u003c/p\u003e\n\u003cp\u003e106\u003c/p\u003e\n\u003cp\u003eServer ver: 5.1.22-rc-community-log, Binlog ver: 4\u003c/p\u003e\n\u003cp\u003e3、我做了几次操作后，她就记录了下来。\u003c/p\u003e\n\u003cp\u003e又一次 show binlog events 的结果。 …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e12.1优化表的数据类型\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e表需要使用何种数据类型，是需要根据应用来判断的。虽然应用设计的时候需要考虑字段的长度留有一定的冗余，但是不推荐让很多字段都留有大量的冗余，这样即浪费存储也浪费内存。\u003c/p\u003e\n\u003cp\u003e我们可以使用PROCEDUREANALYSE()对当前已有应用的表类型的判断，该函数可以对数据表中的列的数据类型提出优化建议，可以根据应用的实际情况酌情考虑是否实施优化。\u003c/p\u003e\n\u003cp\u003e语法：\u003c/p\u003e\n\u003cp\u003eSELECT * FROM tbl_name PROCEDURE ANALYSE();SELECT * FROM tbl_name PROCEDURE ANALYSE(16,256);\u003c/p\u003e\n\u003cp\u003e输出的每一列信息都会对数据表中的列的数据类型提出优化建议。第二个例子告诉PROCEDUREANALYSE()不要为那些包含的值多于16个或者256字节的ENUM类型提出建议。如果没有这样的限制，输出信息可能很长；ENUM定义通常很难阅读。\u003c/p\u003e\n\u003cp\u003e在对字段类型进行优化时，可以根据统计信息并结合应用的实际情况对其进行优化。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e12.2通过拆分，提高表的访问效率这里我们所说的拆分，主要是针对Myisam类型的表，拆分的方法可以分成两种情况：\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1.  纵 …\u003c/strong\u003e\u003c/p\u003e"

"\u003cp\u003eMySQL还允许改变语句调度的优先级，它可以使来自多个客户端的查询更好地协作，这样单个客户端就不会由于锁定而等待很长时间。改变优先级还可以确保特定类型的查询被处理得更快。\u003c/p\u003e\n\u003cp\u003e我们首先应该确定应用的类型，判断应用是以查询为主还是以更新为主的，是确保查询效率还是确保更新的效率，决定是查询优先还是更新优先。\u003c/p\u003e\n\u003cp\u003e下面我们提到的改变调度策略的方法主要是针对Myisam存储引擎的，对于Innodb存储引擎，语句的执行是由获得行锁的顺序决定的。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMySQL的默认的调度策略可用总结如下：\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e写入操作优先于读取操作。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e对某张数据表的写入操作某一时刻只能发生一次，写入请求按照它们到达的次序来处理。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e对某张数据表的多个读取操作可以同时地进行。\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003eMySQL提供了几个语句调节符，允许你修改它的调度策略：\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003eLOW_PRIORITY关键字应用于DELETE、INSERT、LOADDATA、REPLACE和UPDATE。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eHIGH_PRIORITY关键字应用于SELECT和INSERT语句。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eDELAYED关键字应用于INSERT和REPLACE语句。\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e如果写入操作是一 …\u003c/p\u003e"

"\u003cp\u003eMysql4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，子查询可以被更有效率的连接(JOIN).. 替代。\u003c/p\u003e\n\u003cp\u003e假设我们要将所有没有订单记录的用户取出来，可以用下面这个查询完成：\u003c/p\u003e\n\u003cp\u003eSELECT * FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID  FROM salesinfo)\u003c/p\u003e\n\u003cp\u003e如果使用连接(JOIN)..来完成这个查询工作，速度将会快很多。尤其是当salesinfo 表中对CustomerID建有索引的话，性能将会更好，查询如下：\u003c/p\u003e\n\u003cp\u003eSELECT * FROM customerinfo\nLEFT JOIN salesinfo ON customerinfo.CustomerID=salesinfo.CustomerID\nWHERE salesinfo.CustomerID IS NULL\u003c/p\u003e\n\u003cp\u003e连 …\u003c/p\u003e"

"\u003cp\u003e在某些情况中，MySQL可以使用一个索引来满足ORDER BY子句，而不需要额外的排序。where条件和order by使用相同的索引，并且order by的顺序和索引顺序相同， 并且order by的字段都是升序或者都是降序。\u003c/p\u003e\n\u003cp\u003e例如：下列sql可以使用索引。\u003c/p\u003e\n\u003cp\u003eSELECT * FROM t1 ORDER BY key_part1,key_part2,…;\u003c/p\u003e\n\u003cp\u003eSELECT * FROM t1 WHERE key_part1=1 ORDER BY key_part1 DESC,key_part2 DESC;\u003c/p\u003e\n\u003cp\u003eSELECT * FROM t1 ORDER BY key_part1 DESC,key_part2 DESC;\u003c/p\u003e\n\u003cp\u003e**但是以下情况不使用索引： **\u003c/p\u003e\n\u003cp\u003eSELECT * FROM t1 ORDER BY key_part1 DESC,key_part2 ASC；\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e–orderby的字段混合ASC和DESC\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e**\n**\u003c/p\u003e\n\u003cp\u003eSELECT * FROM t1 WHERE key2=constant ORDER BY key1；\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e–用于查询行的关键字与ORDERBY中所使用的不相同\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e**\n** …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e1.1优化SQL的一般步骤\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e11.1.1\u003c/strong\u003e \u003cstrong\u003e通过show status和应用特点了解各种SQL的执行频率\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e通过SHOW STATUS可以提供服务器状态信息，也可以使用mysqladminextended- status命令获得。SHOW STATUS可以根据需要显示session级别的统计结果和global 级别的统计结果。\u003c/p\u003e\n\u003cp\u003e以下几个参数对Myisam和Innodb存储引擎都计数：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003eCom_select 执行select操作的次数，一次查询只累加1；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eCom_insert执行insert操作的次数，对于批量插入的insert操作，只累加一次；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eCom_update执行update操作的次数；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eCom_delete 执行delete操作的次数；\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e以下几个参数是针对Innodb存储引擎计数的，累加的算法也略有不同：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003eInnodb_rows_read select查询返回的行数；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eInnodb_rows_inserted执行Insert操作插入的行数；\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eInnodb_rows_updated执行update操作更新的行数； …\u003c/p\u003e\u003c/li\u003e\u003c/ol\u003e"

"\u003cp\u003e\u003cstrong\u003e10.1数据库名、表名大小写问题\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e在MySQL中，数据库对应数据目录中的目录。数据库中的每个表至少对应数据库目录中的一个文件(也可能是多个，取决于存储引擎)。因此，所使用操作系统的大小写敏感性决定了数据库名和表名的大小写敏感性。这说明在大多数Unix中数据库名和表名对大小写敏感，而在Windows中对大小写不敏感。一个显著的例外情况是MacOSX，它基于Unix但使用默认文件系统类型(HFS+)，对大小写不敏感。然而，MacOSX也支持UFS卷，该卷对大小写敏感，就像Unix一样。\u003c/p\u003e\n\u003cp\u003e注释：尽管在某些平台中数据库名和表名对大小写不敏感，不应在同一查询中使用不同的大小写来引用给定的数据库或表。下面的查询不会工作，因为它同时引用了表my_tables和as\nMY_tables：mysql\u0026gt;SELECT* FROMmy_tableWHERE MY_TABLE.col=1;列、索引、存储子程序和触发器名在任何平台上对大小写不敏感，列的别名也不敏感。\u003c/p\u003e\n\u003cp\u003e默认情况，表别名在Unix中对大小写敏感，但在Windows或MacOSX中对大小写不敏感。\u003c/p\u003e\n\u003cp\u003e下面的查询在Unix中不会工作，因为它同时引用了 …\u003c/p\u003e"

"\u003cp\u003emysql 的字符集和校对规则有 4 个级别的默认设置：\u003cstrong\u003e服务器级、数据库级、表级\u003c/strong\u003e 和 \u003cstrong\u003e字段级\u003c/strong\u003e。分别在不同的地方设置，作用也不相同。服务器字符集和校对，在 mysql 服务启动的时候确定。\u003c/p\u003e\n\u003cp\u003e可以在 \u003cstrong\u003emy.cnf\u003c/strong\u003e 中设置：\n[mysqld]\n\u003cstrong\u003edefault-character-set=utf8\u003c/strong\u003e\n或者在启动选项中指定：\n\u003cstrong\u003emysqld –default-character-set=utf8\u003c/strong\u003e\n或者在编译的时候指定：\n./configure –with-charset=utf8\n如果没有特别的指定服务器字符集，默认使用 latin1 作为服务器字符集。上面三种 设置的方式都只指定了字符集，没有指定校对规则，这样是使用该字符集默认的校对规则， 如果要使用该字符集的非默认校对规则，则需要在指定字符集的同时指定校对规则。\n可以用 show variables like ‘character_set_server’; 命令查询当前服务器的字符集和校对规则。\u003c/p\u003e"

"\u003cp\u003eshow table status\u003c/p\u003e\n\u003cp\u003e通过show table status where name =’表名’; 可以查看指定表的信息\u003c/p\u003e"

"\u003cp\u003e可以参考一下官方文档中的解释。\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/optimization.html\"\u003ehttp://dev.mysql.com/doc/refman/5.1/zh/optimization.html\u003c/a\u003e\u003c/p\u003e\n\u003col start=\"7\"\u003e\n\u003cli\u003e优化\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e7.1. 优化概述\u003c/p\u003e\n\u003cp\u003e7.1.1. MySQL设计局限与折衷\u003c/p\u003e\n\u003cp\u003e7.1.2. 为可移植性设计应用程序\u003c/p\u003e\n\u003cp\u003e7.1.3. 我们已将MySQL用在何处？\u003c/p\u003e\n\u003cp\u003e7.1.4. MySQL基准套件\u003c/p\u003e\n\u003cp\u003e7.1.5. 使用自己的基准\u003c/p\u003e\n\u003cp\u003e7.2. 优化SELECT语句和其它查询\u003c/p\u003e\n\u003cp\u003e7.2.1. EXPLAIN语法（获取SELECT相关信息）\u003c/p\u003e\n\u003cp\u003e7.2.2. 估计查询性能\u003c/p\u003e\n\u003cp\u003e7.2.3. SELECT查询的速度\u003c/p\u003e\n\u003cp\u003e7.2.4. MySQL怎样优化WHERE子句\u003c/p\u003e\n\u003cp\u003e7.2.5. 范围优化\u003c/p\u003e\n\u003cp\u003e7.2.6. 索引合并优化\u003c/p\u003e\n\u003cp\u003e7.2.7. MySQL如何优化IS NULL\u003c/p\u003e\n\u003cp\u003e7.2.8. MySQL如何优化DISTINCT\u003c/p\u003e\n\u003cp\u003e7.2.9. MySQL如何优化LEFT JOIN和RIGHT JOIN\u003c/p\u003e\n\u003cp\u003e7.2.10. MySQL如何优化嵌套Join\u003c/p\u003e\n\u003cp\u003e7.2.11. MySQL如何简化外部联合\u003c/p\u003e\n\u003cp\u003e7.2.12. MySQL如何优化ORDER BY\u003c/p\u003e\n\u003cp\u003e7.2.13. MySQL如何优化GROUP BY …\u003c/p\u003e"

"\u003cp\u003e法一:\u003c/p\u003e\n\u003cp\u003e先是上网找了一下资料，说是MYSQL会反查DNS，比较烦人的，2楼写上网上搜索到的资料(有弊端)，先说一下我的处理办法\u003c/p\u003e\n\u003cp\u003e今天有两个网站(A站和B站)，程序一样，分别放在两台服务器，数据库放在A站，B站程序的数据库连接，指向A站IP\u003c/p\u003e\n\u003cp\u003e但是访问B站的时候，速度奇慢，这两台服务器还都在同一机房，应该属于局域网，查到资料说是MYSQL对DNS进行反查，这样也好办，我只有这一个站需要远程访问MYSQL，设置一下HOSTS文件，不让A站(数据库服务器端)反查DNS就行了\u003c/p\u003e\n\u003cp\u003e修改c:\\windows\\system32\\drivers\\etc\\hosts文件\u003c/p\u003e\n\u003cp\u003e添加\u003c/p\u003e\n\u003cp\u003eB站IP    B站域名\u003c/p\u003e\n\u003cp\u003e这样就避免A站(数据库服务器端)不再反查DNS，刷新页面，快了N倍，呵呵，如果按2楼的方法修改，是一劳永逸的，适合有很多站需要远程访问，比如卖空间的，但是有弊端，就是以后就不能再使用主机名连接MYSQL了，具体介绍看2楼\u003c/p\u003e\n\u003cp\u003e=========================================\u003c/p\u003e\n\u003cp\u003e法二:\u003c/p\u003e\n\u003cp\u003e服务器放在局域网内进行测试时，数据库的访问速度还是很快。但当服务器放到外网后，数据库的访问速度就变 …\u003c/p\u003e"

"\u003cp\u003eREPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE\n[pre] tbl_name[,tbl_name] … [QUICK] [EXTENDED] [USE_FRM]\u003c/p\u003e\n\u003cp\u003eREPAIR TABLE用于修复被破坏的表。默认情况下，REPAIR TABLE与 myisamchk –recovertbl_name具有相同的效果。REPAIR TABLE对MyISAM和ARCHIVE表起作用。    通 常，您基本上不必运行此语句。但是，如果灾难发生，REPAIR TABLE很有可能从MyISAM表中找回所有数据。如果您的表经常被破坏，您应该尽力 找到原因，以避免使用REPAIR TALBE。请参见A.4.2节，“如果MySQL依然崩溃，应作些什么”。同时也见15.1.4节，“MyISAM 表方面的问题”。\n本语句会返回一个含有以下列的表：\n\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/20094147086.jpg\" alt=\"20094147086\"\u003e\u003c/p\u003e\n\u003cp\u003e对 于每个被修复的表，REPAIR TABLE语句会产生多行的信息。上一行含有一个Msg_type状态值。Msg_test通常应为OK。如果您没有得 到OK，您应该尝试使用myisamchk –safe-recover修复表，因 …\u003c/p\u003e"

"\u003cp\u003e检查表: CHECKTABLE`tablename1`[,`tablename2`]\u003c/p\u003e\n\u003cp\u003e优化表: OPTIMIZE TABLE `tablename1` [, `tablename2`]\u003c/p\u003e\n\u003cp\u003e修复表: REPAIR TABLE `tablename1` [, `tablename2`]\u003c/p\u003e\n\u003cp\u003e分析表: ANALYZE TABLE `tablename1` [, `tablename2`]\u003c/p\u003e"

"\u003cp\u003e测试环境：mysql 5.0.45\n【注：可以在mysql中通过mysql\u0026gt; SELECT VERSION();来查看数据库版本】\u003c/p\u003e\n\u003cp\u003e一、连接MYSQL。\u003c/p\u003e\n\u003cp\u003e格式： mysql -h主机地址 -u用户名 －p用户密码\u003c/p\u003e\n\u003cp\u003e1、连接到本机上的MYSQL。\u003c/p\u003e\n\u003cp\u003e首先打开DOS窗口，然后进入目录mysql\\bin，再键入命令mysql -u root -p，回车后提示你输密码.注意用户名前可以有空格也可以没有空格，但是密码前必须没有空格，否则让你重新输入密码.\u003c/p\u003e\n\u003cp\u003e如果刚安装好MYSQL，超级用户root是没有密码的，故直接回车即可进入到MYSQL中了，MYSQL的提示符是： mysql\u0026gt;\u003c/p\u003e\n\u003cp\u003e2、连接到远程主机上的MYSQL。假设远程主机的IP为：110.110.110.110，用户名为root,密码为abcd123。则键入以下命令：\u003c/p\u003e\n\u003cp\u003emysql -h110.110.110.110 -u root -p 123;（注:u与root之间可以不用加空格，其它也一样）\u003c/p\u003e\n\u003cp\u003e3、退出MYSQL命令： exit （回车）\u003c/p\u003e\n\u003cp\u003e二、修改密码。\u003c/p\u003e\n\u003cp\u003e格式：mysqladmin -u用户名 -p旧密码 password 新密 …\u003c/p\u003e"

"\u003cp\u003emysql有以下几种日志：\n错误日志：   -log-err\n查询日志：   -log\n慢查询日志:     -log-slow-queries\n更新日志:     -log-update\n二进制日志：   -log-bin\u003c/p\u003e\n\u003cp\u003e在mysql的安装目录下，打开my.ini,在后面加上上面的参数，保存后重启mysql服务就行了。\n例如：\n#Enter   a   name   for   the   binary   log.   Otherwise   a   default   name   will   be   used.\n\u003cstrong\u003e#log-bin=\u003c/strong\u003e\n#Enter   a   name   for   the   query   log   file.   Otherwise   a   default   name   will   be   used.\n\u003cstrong\u003e#log=\u003c/strong\u003e\n#Enter   a   name   for   the   error   log   file.   Otherwise   a   default   name   will   be   used. …\u003c/p\u003e"

"\u003cp\u003e修改my.ini文件\u003c/p\u003e\n\u003cp\u003e加上\u003c/p\u003e\n\u003cp\u003edefault-character-set=gb2312\u003c/p\u003e\n\u003cp\u003e设定数据库字符集\u003c/p\u003e\n\u003cp\u003ealter database da_name default character set ‘charset’\u003c/p\u003e\n\u003cp\u003e1)设置数据库编码 /etc/my.cnf\n[mysqld]\ndefault-character-set=gbk\n…\n[client]\ndefault-character-set=gbk\n－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－\n2)按字符集导出\n$mysqldump -u root -p dbname –default-character-set=gbk \u0026gt; a.sql;\n3)查看SQL文件的编码\n[root@localhost gethtml]# file a.sql\na.sql: UTF-8 Unicode …\n[root@localhost gethtml]# iconv -f utf-8 -t gbk a.sql \u0026gt; a2.sql\n[root@localhost gethtml]# file a2.sql …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e目录\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-overview\"\u003e18.1. MySQL中的分区概述\u003c/a\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-types\"\u003e18.2. 分区类型\u003c/a\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-range\"\u003e18.2.1. RANGE分区\u003c/a\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-list\"\u003e18.2.2. LIST分区\u003c/a\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-hash\"\u003e18.2.3. HASH分区\u003c/a\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-key\"\u003e18.2.4. KEY分区\u003c/a\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-subpartitions\"\u003e18.2.5. 子分区\u003c/a\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-handling-nulls\"\u003e18.2.6. MySQL分区处理NULL值的方式\u003c/a\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-management\"\u003e18.3. 分区管理\u003c/a\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-management-range-list\"\u003e18.3.1. RANGE和LIST分区的管理\u003c/a\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-management-hash-key\"\u003e18.3.2. HASH和KEY分区的管理\u003c/a\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-maintenance\"\u003e18.3.3. 分区维护\u003c/a\u003e\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-info\"\u003e18.3.4. 获取关于分区的信息\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e本章讨论MySQL 5.1.中实现的分区。关于分区和分区概念的介绍可以在\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-overview\" title=\"18.1. Overview of Partitioning in MySQL\"\u003e18.1节，“MySQL中的分区概述”\u003c/a\u003e中找到。MySQL 5.1 支持哪几种类型的分区，在\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-types\" title=\"18.2. Partition Types\"\u003e18.2节，“分区类型”\u003c/a\u003e 中讨论。关于子分区在\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-subpartitions\" title=\"18.2.5. Subpartitioning\"\u003e18.2.5节，“子分区”\u003c/a\u003e 中讨论。现有分区表中分区的增加、删除和修改的方法在\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-management\" title=\"18.3. Partition Management\"\u003e18.3节，“分区管理”\u003c/a\u003e 中介绍。 和分区表一同使用的表维护命令在\u003ca href=\"http://dev.mysql.com/doc/refman/5.1/zh/partitioning.html#partitioning-maintenance\" title=\"18.3.3. Maintenance of Partitions\"\u003e18.3.3节，“分区维护”\u003c/a\u003e 中介绍。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e请注意\u003c/strong\u003e：MySQL 5.1中的分区实现仍然很新（pre-alpha品质），此时还不是可生产的（not production-ready）。 同样，许多也适用于本章：在这里描述的一些功能还没有实际上 …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e1、概述\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e通常，从一个发布版本升级到另一个版本时，我们建议按照顺序来升级版本。例如，想要升级 MySQL 3.23 时，先升级到 MySQL 4.0，而不是直接升级到 MySQL 4.1 或 MySQL 5.0。\u003c/p\u003e\n\u003cp\u003e以下是在升级 MySQL 时需要注意的事项：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e仔细阅读一下升级的目标版本的新特性和改变的特性，以及2个版本之间的不同特性\u003c/li\u003e\n\u003cli\u003e升级前一定要备份所有的数据\u003c/li\u003e\n\u003cli\u003e如果是在Windows平台上升级MySQL，请阅读附录 “\u003ca href=\"http://imysql.cn/node/74#upgrade_on_ms\"\u003e在Windows平台上升级MySQL\u003c/a\u003e“\u003c/li\u003e\n\u003cli\u003e有些不同版本间的升级可能会涉及对授权表的修改，请尤其注意这个问题，详情请阅读附录 “\u003ca href=\"http://imysql.cn/node/74#upgrade_grants_table\"\u003e升级授权表\u003c/a\u003e“\u003c/li\u003e\n\u003cli\u003e如果正在运行着同步，请阅读附录 “\u003ca href=\"http://imysql.cn/node/74#upgrade_replication\"\u003e升级同步\u003c/a\u003e“\u003c/li\u003e\n\u003cli\u003e如果之前运行着MySQL-Max发布版本，想要升级到非MySQL-Max发布版本时，就需要从 mysqld_safe 去掉启动 mysqld-max 服务器的参数\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e在同一个发布系列版本的MySQL间，可以随意拷贝格式文件和数据文件。如果在MySQL运行过程中改变了字符集，就需要对每个MyISAM表执行 “ \u003cstrong\u003emyisamchk -r -q –set-character-set= …\u003c/strong\u003e\u003c/p\u003e"

"\u003ch1 id=\"6-mysql-同步\"\u003e\u003ca href=\"javascript:void(0);\"\u003e6 MySQL 同步\u003c/a\u003e\u003c/h1\u003e\n\u003cp\u003e同步功能在MySQL 3.23.15就开始引进了，它可以把一个MySQL服务器上的数据复制到另一个服务器上去。本章描述了MySQL的各种复制特性。介绍了同步的概念，如何设置同步服务器，以及可用服务器的参照。还提供了一系列的常见问题及其答案，疑难解答。\u003c/p\u003e\n\u003cp\u003e“\u003ca href=\"javascript:void(0);\"\u003e14.6 Replication Statements\u003c/a\u003e“中介绍了同步相关的SQL语句语法。\u003c/p\u003e\n\u003cp\u003e我们建议经常访问”\u003ca href=\"javascript:void(0);\"\u003ehttp://www.mysql.com\u003c/a\u003e“经常阅读本章的最新内容。同步功能一直在改进，我们经常把这部分的手册更新到当前的最新内容。\u003c/p\u003e\n\u003ch2 id=\"61-同步介绍\"\u003e\u003ca href=\"javascript:void(0);\"\u003e6.1 同步介绍\u003c/a\u003e\u003c/h2\u003e\n\u003cp\u003eMySQL 3.23.15及更高的版本支持单向同步。一个服务器作为master(主服务器)，一个或者多个服务器作为slave(从服务器)。master服务器 把更新的内容写到二进制日志(binary log或binlog)中，并且维护了一个索引文件来记录日志循环的情况。这些日志中的更新部分会被发送到slave服务器。一个slave连接到 master之后，它通知master最后一次成功增量更新的日志位置。slave会找出所有从那个时刻开始的更新操作，然后阻塞并 …\u003c/p\u003e"

"\u003cp\u003eMaster: 192.168.1.200\nslave: 192.168.1.201\u003c/p\u003e\n\u003cp\u003e1： 首先确定Master和Slave的数据库版本，Master数据库的版本不能高于Slave数据的版本。\u003c/p\u003e\n\u003cp\u003e这里我是使用MySql 5.0.27 作为Master数据库，MySql 6.0.3（alpha）作为Slave进行测试。\u003c/p\u003e\n\u003cp\u003e2：首先在Master数据库的配置文件my.ini (windows)里添加log-bin 和 server-id 两项\u003c/p\u003e\n\u003cp\u003eeg: [mysqld]\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eserver-id = 1  //服务器编号\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003elog-bin = mysql-bin  //使用的二进制日志文件名\nbinlog-do-db=test = maindb //同步的数据库(不记录二进制日志)\u003c/strong\u003e\n\u003cstrong\u003ebinlog-ignore-db=bbs\u003c/strong\u003e \u003cstrong\u003e//不允许同步的数据库(不记录二进制日志)\u003c/strong\u003e\n\u003cstrong\u003ebinlog-ignore-db=ceshi   //不允许同步的数据库库(不记录二进制日志)\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e在Slave数据库的配置文件my.ini里添加server-id 项\u003c/p\u003e\n\u003cp\u003eeg:[mysqld]\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eserver-id = 2\n** …\u003c/strong\u003e\u003c/p\u003e"

"\u003cp\u003e在mysql上一般的查询要么是按一个字段的升序，要么按降序进行排序，如果实现根据条件里值的左右顺序来显示记录呢，如 where id in (3,1,5,2)此类的，查询出来的记录从上到下也是(3,1,5,2)这类的顺序了，可以用以下语句来实现：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eSELECT * FROM documents WHERE id IN (3,5,7) ORDER BY FIELD(id,3,5,7)\n\u003c/code\u003e\u003c/pre\u003e"

"\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql\u0026gt; select database();\n+------------+\n| database() |\n+------------+\n| csdn |\n+------------+\n1 row in set (0.00 sec)\n\nmysql\u0026gt; SELECT * FROM information_schema.SCHEMATA where schema_name=\u0026#39;csdn\u0026#39;;\n+--------------+-------------+----------------------------+------------------------+----------+\n| CATALOG_NAME | SCHEMA_NAME | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | SQL_PATH | …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e在数据库中，UNION和UNION ALL关键字都是将两个结果集合并为一个，但这两者从使用和效率上来说都有所不同。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMySQL中的UNION\u003c/strong\u003e\nUNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。实际大部分应用中是不会产生重复的记录，最常见的是过程表与历史表UNION。如：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003ccode\u003eselect * from gc_dfys union select * from ls_jg_dfys\u003c/code\u003e\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e这个SQL在运行时先取出两个表的结果，再用排序空间进行排序删除重复的记录，最后返回结果集，如果表数据量大的话可能会导致用磁盘进行排序。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMySQL中的UNION ALL\u003c/strong\u003e\n而UNION ALL只是简单的将两个结果合并后就返回。这样，如果返回的两个结果集中有重复的数据，那么返回的结果集就会包含重复的数据了。\n从效率上说，UNION ALL 要比UNION快很多，所以，如果可以确认合并的两个结果集中不包含重复的数据的话，那么就使用UNION ALL，如下：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003ccode\u003eselect * from gc_dfys union all select * from …\u003c/code\u003e\u003c/p\u003e\u003c/blockquote\u003e"

"\u003cp\u003e一次为了修改mysql的root用户密码，就启用了本机启动模式，可再次启用mysql时，却揭示：Default storage engine (InnoDB) is not available ，mysql无法启动，后搜索网络，得知应该是配置文件有错，这里提示：“060827  1:12:22 [ERROR] Default storage engine (InnoDB) is not available”\n打开my.ini或my.cnf文件，找到default-storage-engine这一行，把它改成default-storage-engine=MyISAM。\u003c/p\u003e"

"\u003cp\u003e用EXPLAIN看MySQL的执行计划时经常会看到Impossible WHERE noticed after reading const tables这句话，意思是说MySQL通过读取“const tables”，发现这个查询是不可能有结果输出的。比如对下面的表和数据：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e create table t (a int primary key, b int) engine = innodb;\n insert into t values(1, 1);\n insert into t values(3, 1);\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e执行“EXPLAIN select * from t where a = 2”时就会输出“Impossible WHERE noticed after reading const tables”。\u003c/p\u003e\n\u003cp\u003e不 明白所谓的“const tables”是什么意思，对MySQL在查询优化时竟然可以发现一个查询不可能输出结果更是感觉不可思议。按数据库中“传统”的做法，查询优化时只会访 问模式定义和统计信息，而据我所知，数据库中使用的各种统计信息如EquiDepth、MaxDiff柱状图，MCV， …\u003c/p\u003e"

"\u003ch2 id=\"服务器生成的二进制日志文件写成二进制格式要想检查这些文本格式的文件应使用mysqlbinlog实用工具\"\u003e服务器生成的二进制日志文件写成二进制格式。要想检查这些文本格式的文件，应使用mysqlbinlog实用工具。\u003c/h2\u003e\n\u003cp\u003e应这样调用mysqlbinlog：shell\u0026gt; \u003cstrong\u003emysqlbinlog [options] \u003cem\u003elog-files\u003c/em\u003e…\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e例如，要想显示二进制日志binlog.000003的内容，使用下面的命令：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eshell\u0026gt; mysqlbinlog binlog.0000003\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e输出包括在binlog.000003中包含的所有语句，以及其它信息例如每个语句花费的时间、客户发出的线程ID、发出线程时的时间戳等等。\u003c/p\u003e\n\u003cp\u003e通常情况，可以使用\u003cstrong\u003emysqlbinlog\u003c/strong\u003e直接读取二进制日志文件并将它们用于本地MySQL服务器。也可以使用–read-from-remote-server选项从远程服务器读取二进制日志。\u003c/p\u003e\n\u003cp\u003e当读取远程二进制日志时，可以通过连接参数选项来指示如何连接服务器，但它们经常被忽略掉，除非你还指定了–read-from-remote-server选项。这些选项是–host、–password、–port、–protocol、–socket和–user。\u003c/p\u003e\n\u003cp\u003e还可以使用\u003cstrong\u003emysqlbinlog\u003c/strong\u003e来读取 …\u003c/p\u003e"

"\u003cp\u003emysql有一个功能就是可以log下来运行的比较慢的sql语句，默认是没有这个log的，为了开启这个功能，\n要修改my.cnf或者在mysql启动的时候加入一些参数。如果在my.cnf(Windows为my.ini文件)里面修改，需增加如下几行\u003c/p\u003e\n\u003cp\u003e`long_query_time = 1\u003c/p\u003e\n\u003cp\u003elog-slow-queries = /var/youpath/slow.log\u003c/p\u003e\n\u003cp\u003elog-queries-not-using-indexes`\u003c/p\u003e\n\u003cp\u003elong_query_time 是指执行超过多久的sql会被log下来，这里是1秒。\nlog-slow-queries 设置把日志写在那里，可以为空，系统会给一个缺省的文件host_name-slow.log，\nlog-queries-not-using-indexes 就是字面意思，log下来没有使用索引的query。\u003c/p\u003e\n\u003cp\u003emysql有以下几种日志：\n\u003cstrong\u003e错误日志：   -log-err\n查询日志：   -log\n慢查询日志:     -log-slow-queries\n更新日志:     -log-update\n二进制日志：   -log-bin\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e把上述参数打开，运 …\u003c/p\u003e"

"\u003cp\u003eMySQL数据库双机热备的配置方法:\u003c/p\u003e\n\u003cp\u003e◆1.MySQL数据库没有增量备份的机制，当数据量太大的时候备份是一个很大的问题。还好MySQL数据库提供了一种主从备份的机制，其实就是把主数据库的所有的数据同时写到备份数据库中。实现MySQL数据库的热备份。\u003c/p\u003e\n\u003cp\u003e◆2.要想实现双机的热备首先要了解主从数据库服务器的版本的需求。要实现热备MySQL的版本都要高于3.2，还有一个基本的原则就是作为从数据库的数据库版本可以高于主服务器数据库的版本，但是不可以低于主服务器的数据库版本。\u003c/p\u003e\n\u003cp\u003e◆3.设置主数据库服务器：\u003c/p\u003e\n\u003cp\u003e·a.首先查看主服务器的版本是否是支持热备的版本。然后查看my.cnf(类 unix)或者my.ini(windows)中mysqld配置块的配置有没有log-bin(记录数据库更改日志)，因为MySQL的复制机制是基于 日志的复制机制，所以主服务器一定要支持更改日志才行。然后设置要写入日志的数据库或者不要写入日志的数据库。这样只有您感兴趣的数据库的更改才写入到数 据库的日志中。\u003c/p\u003e\n\u003cp\u003eserver-id=1 //数据库的id这个应该默认是1就不用改动\u003c/p\u003e\n\u003cp\u003elog-bin=log_name //日志文件的名 …\u003c/p\u003e"

"\u003cp\u003eChanged limits: max_open_files: 2048 max_connections: 1024 table_cache: 507\u003c/p\u003e\n\u003cp\u003e这个问题怎么解决啊！\u003c/p\u003e\n\u003cp\u003e在windows下安装Mysql系统日志出现 max_open_files: 2048 max_connections: 510 table_cache: 764 类似错误是因为 \u003cstrong\u003emax_connections\u003c/strong\u003e 最大连接数和\u003cstrong\u003emax_open_files\u003c/strong\u003e、\u003cstrong\u003etable_cache\u003c/strong\u003e 不匹配。适当的降低max_connections 或调整其他两个数值\n解决办法在 mysql bin \u0026gt; 中输入\nmysql-nt –table_cache=764\nmysql-nt –innodb_open_files=2048   即可！！\u003c/p\u003e\n\u003cp\u003etable_cache和max_connections 在my.ini 里可调\u003c/p\u003e\n\u003cp\u003eChanged limits:\nmax_open_files: 2048\nmax_connections: 1024\ntable_cache: 507\u003c/p\u003e\n\u003cp\u003emax_connections=1024 …\u003c/p\u003e"

"\u003cp\u003eMySql Query Cache 和 Oracle  Query Cache 是不同的， Oracle Query Cache 是缓存执行计划的，而MySql Query Cache 不缓存执行计划而是整个结果集。缓存整个结果集的好处不言而喻，但由于缓存的是结果集因此Query必须是完全一样的，这样带来的后果就是平均 Hit Rate 命中率一般不会太高。 Query Cache 对于一些小型应用程序或者数据表的数据量不大的情况下效果是最为明显的。\u003c/p\u003e\n\u003cp\u003e作为一个新的特性，MySql Query Cache 有什么特典和局限呢？ 咱一个一个来说：\u003c/p\u003e\n\u003cp\u003e1、Cache 机制对应用程序是透明的。在应用程序中只是改变查询语句的语义，也能得到缓存中的查询结果集。如果你没有使用 query_cache_wlock_invalidate=ON   来提示MySql 锁表将要进行写操作，那么此时的查询即使表在锁Lock状态下或者预备更新的状态下，仍然可以从缓存中获得结果集；\u003c/p\u003e\n\u003cp\u003e2、只缓存整个查询结果集，即对子查询，内联视图和部分UNION的查询是不缓存的；\u003c/p\u003e\n\u003cp\u003e3、缓存机制工作在Packet 级别，第二项的只缓存 …\u003c/p\u003e"

"\u003cp\u003e症状：\nMySQL重启后，发现连接非常慢，建立连接后做普通操作还是非常快的，通过Show processlist发现大量unauthenticated user连接\u003c/p\u003e\n\u003cp\u003e解决办法：\nMySQL启动参数增加一个skip-name-resolve，即不启用DNS反响解析\u003c/p\u003e\n\u003cp\u003e解决过程（推荐学习 :)）\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e同一局域网不同机器上连接MySQL服务器，观察响应速度；（非常慢）\u003c/li\u003e\n\u003cli\u003e连接建立后做一些简单的操作（非常快 和上面不符，说明不是服务器压力导致的）\u003c/li\u003e\n\u003cli\u003e通过tcpdump查看连接的时候详细的响应过程（能看到连接的时候和服务器的多次通讯及所耗费的时间）\u003c/li\u003e\n\u003cli\u003e发现正常响应很快，用户名、密码发送完后很长一段时间服务器才给响应\u003c/li\u003e\n\u003cli\u003e在服务器上进行同样的连接连接操作，试着分别用IP和机器名去连接看响应速度（看是不是IP解析的时候耗费时间了）\u003c/li\u003e\n\u003cli\u003e修改/etc/hosts文件，加入服务器、客户端的IP对应（没有作用 :()\u003c/li\u003e\n\u003cli\u003e增加启动参数skip-name-resolve速度立即加快了（问题解决）\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e原因：\nMySQL的认证实际上是user+host的形式（也就是说user可以相同），所以MySQL在处理新连接时会试着去解析客户端 …\u003c/p\u003e"

"\u003cp\u003e今天因为mysql服务没打开，mysql不能使用，以前从没出现这种服务没开启的问题。因为以前服务一直都是开的。\u003c/p\u003e\n\u003cp\u003e一开始以为是权限问题，因为错误提示里有‘localhost’权限的字样，于是狂改，还是一直有问题，网上的类似问题也都试了，都无效。\u003c/p\u003e\n\u003cp\u003e于是决定卸了，重装，但在千钧一发之际，经一哥们指点，发现是服务没开。我晕死……………………………………….\u003c/p\u003e\n\u003cp\u003e看来我的Windows操作也太薄弱了。\u003c/p\u003e\n\u003cp\u003e这不，搞了一天mysql的错误，于是总结如下：\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003e\u003cstrong\u003eMysql 常见错误集锦\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/strong\u003e\u003c/em\u003e******\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1. Host ’…’ is blocked错误\u003c/strong\u003e\n如果你得到象这样的一个错误：\nHost ’hostname’ is blocked because of many connection errors.\nUnblock with ’mysqladmin flush-hosts’\u003c/p\u003e\n\u003cp\u003e这意味着，mysqld已经得到了大量(max_connect_errors)的主机’hostname’的在中途被中断了的连接请求。在max_connect_errors次失败请求后，mysqld认定出错了(象来字一个黑客的攻击)，并且阻止该站 …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003ebulk_insert_buffer_size = n\u003c/strong\u003e\n为一次插入多条新记录的INSERT命令分配的缓存区长度(默认设置是8M)。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ekey_buffer_size = n\u003c/strong\u003e\n用来存放索引区块的RMA值(默认设置是8M)。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ejoin_buffer_size = n\u003c/strong\u003e\n在参加JOIN操作的数据列没有索引时为JOIN操作分配的缓存区长度(默认设置是128K)。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003emax_heap_table_size = n\u003c/strong\u003e\nHEAP数据表的最大长度(默认设置是16M); 超过这个长度的HEAP数据表将被存入一个临时文件而不是驻留在内存里。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003emax_connections = n\u003c/strong\u003e\nMySQL服务器同时处理的数据库连接的最大数量(默认设置是100)。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003equery_cache_limit = n\u003c/strong\u003e\n允许临时存放在查询缓存区里的查询结果的最大长度(默认设置是1M)。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003equery_cache_size = n\u003c/strong\u003e\n查询缓存区的最大长度(默认设置是0，不开辟查询缓存区)。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003equery_cache_type = 0/1/2\u003c/strong\u003e\n查询缓存区的工作模式:0, 禁用查询缓存区; 1，启用查询缓存区(默认设置); 2，”按需分配”模式，只响 …\u003c/p\u003e"

"\u003cp\u003e网上有很多的文章教怎么配置MySQL服务器，但考虑到服务器硬件配置的不同，具体应用的差别，那些文章的做法只能作为初步设置参考，我们需要根据自己的情况进行配置优化，好的做法是MySQL服务器稳定运行了一段时间后运行，根据服务器的”状态”进行优化。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003emysql\u0026gt; show global status;\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e可以列出MySQL服务器运行各种状态值，另外，查询MySQL服务器配置信息语句：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003emysql\u0026gt; show variables;\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003e一、慢查询\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003c/blockquote\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003emysql\u0026gt; show variables like \u0026#39;%slow%\u0026#39;;\n+------------------+-------+\n| Variable_name    | Value |\n+------------------+-------+\n| log_slow_queries | ON    |\n| slow_launch_time | 2     |\n+------------------+-------+\n\nmysql\u0026gt; show global status like …\u003c/code\u003e\u003c/pre\u003e"

"\u003cp\u003e字符串，恐怕应该算是MYSQL里面最复杂的类型了吧？几乎目前所有的问题，都是出在与字符有关的数据列上，大致有几种\n1、字符串的查询（以下如果不特指，都是指中文），搜索一个中文的时候，不管是模糊还是精确，往往结果都会有与搜索内容不一致的数据在里面\n2、编码，现在大家都知道MYSQL连接上后，先执行一下mysql_query(‘set names GBK’,$conn)这类的语句，从MYSQL4.0升级到4.1及以上版本的朋友在这上面吃的苦不少了。网上关于这类的提问也是最多的\n3、索引、效率，varchar是MYSQL所特有的字段，而且长度可变，char则是固定长度的字符串。\n在MYSQL所支持的几个字符串格式里面，char和varchar是用的最多的，char是定长字段，，也就是说，不管字符串的实际长度有多少，CHAR(10)将永远占用10个字节。字符串如果前端有空格，那么在存储的时候会自动被数据库去掉，相当于先执行trim($string)，再进行存储，如果不满10个字节，将会采用空格填满，读取数据时，MYSQL会自动将这些空格去掉。看到这里，恐怕它的缺点之一就明显的暴露了，CHAR不 …\u003c/p\u003e"

"\u003cp\u003e9.9.6 自动修改数据表的设计(默许的数据列修改)\u003c/p\u003e\n\u003cp\u003e在创建(create table)或修改(alter table)一个数据表的时候，MYSQL会在特定条件下对这个数据表的设计方案自动做出一些修改，其理由或者是那么做可以让数据表的效率更高，或者是设计思路MYSQL无法实现.\n这里要特别提醒那些从期货数据库系统迁移过来的读者注意：MYSQL在对数据表设计方案自动做出勤率修改时不会给出任何提示，所以一事实上要用SHOW CREATE TABLE命令去检查一下最终的数据表设计方案是不是所想像的样子。在下面的例子里。MYSQL自做主张地把一个CHAR(2)数据列改成了一个VARCHAR(20)数据列，还给那两个数据列加上了defautl null属性.\n\u003cstrong\u003eCREATE TABLE test1(col1 VARCHAR(20), col2 CHAR(20))\u003c/strong\u003e\nshow create table test1\n\u003cstrong\u003ecreate table test1(\ncol1 varchar(20) default null,\ncol2 varchar(20) default null\n)engine=MYISAM …\u003c/strong\u003e\u003c/p\u003e"

"\u003cp\u003e修改my.cnf的mysqld部分：\nlong_query_time = 1              //定义慢查询的时间1表示1秒\n–log-slow-queries[=file_name]   //记录慢查询到日志文件\n–log-queries-not-using-indexes //将没使用索引的sql记录到日志文件\n实例：\n[mysqld]\nlong_query_time = 1\nlog-slow-queries = /usr/local/mysql5.0.40/var/slow_query.log\nlog-queries-not-using-indexes = true\u003c/p\u003e\n\u003cp\u003e“too many connections”找不到问题所在,后来发现打开mysql的慢查询会有很大的帮助就搞了一个.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e打开MySQL慢查询\u003c/strong\u003e\nMySQL慢查询记录日志对于跟踪PHP+MySQL体系下的MySQL负载调优问题很有用处，比如安装了很多Discuz!插件的用户，这样可以大概排查出那些插件有代码问题。其实启用MySQL的慢查询日志很简单,只需要在MySQL的配置文件里添 …\u003c/p\u003e"

"\u003cp\u003e在整体的系统运行过程中，数据库服务器 MySQL 的压力是最大的，不仅占用很多的内存和 cpu 资源，而且占用着大部分的磁盘 io 资源，连 PHP 的官方都在声称，说 PHP 脚本 80% 的时间都在等待 MySQL 查询返回的结果。由此可见，提高系统的负载能力，降低 MySQL 的资源消耗迫在眉睫。\n**1、页面缓存功能：\n** 页面缓存功能降低MySQL的资源消耗的（系统本身就已经考虑，采用生成HTML页面，大大降低了数据库的压力）。\n\u003cstrong\u003e2、mysql服务器的优化\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e2.1、修改全站搜索\n修改my.ini(my.cnf) ，在 [mysqld] 后面加入一行“ft_min_word_len=1”，然后重启Mysql，再登录网站后台（模块管理-\u0026gt;全站搜索）重建全文索引。\n2.2、记录慢查询sql语句，修改my.ini(my.cnf)，添加如下代码：\u003c/p\u003e\n\u003cp\u003e#log-slow-queries\nlong_query_time = 1 #是指执行超过多久的 sql 会被 log 下来\nlog-slow-queries = E:/wamp/logs/slow.log #设置把日志写在那里，可以 …\u003c/p\u003e"

"\u003cp\u003e\u003ca href=\"http://www.ningoo.net/html/2007/mysql_replication_configuration.html\"\u003eMySQL Replication\u003c/a\u003e 可以将master的数据复制分布到多个slave上，然后可以利用slave来分担master的读压力。那么对于前台应用来说，就要考虑如何将读的压力分布到多个slave上。如果每个应用都需要来实现读写分离的算法，一则成本太高，二来如果slave增加更多的机器，应用就要随之修改。明显的，如果在应用和数据库间加一个专门用于实现读写分离的中间层，则整个系统的架构拥有更好的扩展性。\u003c/p\u003e\n\u003cp\u003eMySQL Proxy就是这么一个中间层代理，简单的说，MySQL Proxy就是一个连接池，负责将前台应用的连接请求转发给后台的数据库，并且通过使用 \u003ca href=\"http://www.lua.org/\"\u003elua脚本\u003c/a\u003e，可以实现复杂的连接控制和过滤，从而实现读写分离和负载平衡。对于应用来说，MySQL Proxy是完全透明的，应用则只需要连接到MySQL Proxy的监听端口即可。当然，这样proxy机器可能成为单点失效，但完全可以使用多个proxy机器做为冗余，在应用服务器的连接池配置中配置到多个proxy的连接参数即可。\u003c/p\u003e\n\u003cp\u003e安装教程请参考: \u003ca href=\"http://blog.haohtml.com/archives/9465\"\u003ehttp://blog.haohtml.com/archives/9465\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/wp-content/uploads/2009/05/lim98ihh.png\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/lim98ihh.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://forge.mysql.com/wiki/MySQL_Proxy\"\u003eMySQL …\u003c/a\u003e\u003c/p\u003e"

"\u003cp\u003eMySQL Proxy处于客户端应用程序和MySQL服务器之间，通过截断、改变并转发客户端和后端数据库之间的通信来实现其功能，这和\u003cstrong\u003eWinGate\u003c/strong\u003e之类的网络代理服务器的基本思想是一样的。代理服务器是和TCP/IP协议打交道，而要理解MySQL Proxy的工作机制，同样要清楚MySQL客户端和服务器之间的通信协议，\u003cstrong\u003eMySQL Protocol\u003c/strong\u003e包括认证和查询两个基本过程：\u003c/p\u003e\n\u003cp\u003e认证过程包括：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e客户端向服务器发起连接请求\u003c/li\u003e\n\u003cli\u003e服务器向客户端发送握手信息\u003c/li\u003e\n\u003cli\u003e客户端向服务器发送认证请求\u003c/li\u003e\n\u003cli\u003e服务器向客户端发送认证结果\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e如果认证通过，则进入查询过程：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e客户端向服务器发起查询请求\u003c/li\u003e\n\u003cli\u003e服务器向客户端返回查询结果\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e当然，这只是一个粗略的描述，每个过程中发送的包都是有固定格式的，想详细了解MySQL Protocol的同学，可以去 \u003ca href=\"http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol\"\u003e这里\u003c/a\u003e 看看。MySQL Proxy要做的，就是介入协议的各个过程。首先MySQL Proxy以服务器的身份接受客户端请求，根据配置对这些请求进行分析处理，然后以客户端的身份转发给相应的后端数据库服务器，再接受服务器的信息，返回给客户端。所以MySQL Proxy需要同时实现客户端和服务 …\u003c/p\u003e"

"\u003cp\u003e虽然自己不是DBA，但是作为一个程序员，多多少少，应该了解一些数据库方面的东西，并不能只关心程序，不考虑数据库，看到一篇文章，就先转过来，也许以后自己哪天会用到。\u003c/p\u003e\n\u003cp\u003e查看mysql的某个选项\nshow variables like ‘%VAR_NAME%’;\u003c/p\u003e\n\u003cp\u003eselect @@VAR_NAME;\u003c/p\u003e\n\u003cp\u003e    在Linux下管理MySQL数据库的时候总有一些很紧急的情况，发现数据库突然变得压力很大了，那么作为一个DBA，也许需要一些常用的手段或者说命令去分析问题出现在哪里，然后解决：\u003c/p\u003e\n\u003cp\u003e数据库突然产生压力时查看正在查询的SQL:(如果这里内容太多表示并发执行的SQL过多，或许数据库堵塞了，会越来越慢，正常情况下这里应该很少有东西的，也就是连接都在Sleep状态）\n/usr/local/mysql/bin/mysql -uroot -ppassword databaseName  -e “show full processlist” | grep -v Sleep\u003c/p\u003e\n\u003cp\u003e正在运行的SQL太多了，看不过来，那需要排序了，看持续执行时间最长的那些SQL：\n/usr/local/mysql/bin/mysql …\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003e什么是数据库分区？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e　　数据库分区是一种物理数据库设计技术，DBA和数据库建模人员对其相当熟悉。虽然分区技术可以实现很多效果，但其主要目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间。\n分区主要有两种形式：//这里一定要注意行和列的概念（row是行，column是列）\u003c/p\u003e\n\u003cp\u003e　　1. 水平分区（Horizontal Partitioning）这种形式分区是对表的行进行分区，通过这样的方式不同分组里面的物理列分割的数据集得以组合，从而进行个体分割（单分区）或集体分割（1个或多个分区）。所有在表中定义的列在每个数据集中都能找到，所以表的特性依然得以保持。\n　　举个简单例子：一个包含十年发票记录的表可以被分区为十个不同的分区，每个分区包含的是其中一年的记录。（朋奕注：这里具体使用的分区方式我们后面再说，可以先说一点，一定要通过某个属性列来分割，譬如这里使用的列就是年份）\n　　2. 垂直分区（Vertical Partitioning） 这种分区方式一般来说是通过对表的垂直划分来减少目标表的宽度，使某些特定的列 被划分到特定的分区，每个分区都包含了其中的列所对应的行。\n　　举个简单例 …\u003c/p\u003e"

"\u003cp\u003e今天将原网站数据导入新系统的时候,发现用户表是空的,程序前几天很正常的,并没有做任何修改,于是将程序的高度模式打开,发现得到错误提示:”Got error 134 from storage engine”,进到mysql里执行select * from tbl_member limit 100,我没有发现错误的,不过将语句若修改为select * from tbl_member limit 100,10时,又出现了这个错误提示信息,怀疑是mysql表损坏,由于备份的时候,mysql处于运行使用状态,并没有停止服务的,所以才产生了这个错误的\u003c/p\u003e\n\u003cp\u003e于是用 \u003cstrong\u003erepair table tablename\u003c/strong\u003e 命令修复了次用户表,再次执行上述命令,ok,显示执行成功\u003c/p\u003e"

"\u003cp\u003e另一篇文章是用php-fpm方式安装的,用的人也比较的多,推荐使用,这里介绍的是用fastcgi方式安装的.\u003c/p\u003e\n\u003cp\u003e首先在安装所有软件之前新系统ports，然后 再进行下面的工作\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1）安装mysql\u003c/strong\u003e**#cd /usr/ports/databases/mysql51-server**\u003c/p\u003e\n\u003cp\u003e**#make WITH_CHARSET=gbk WITH_XCHARSET=all ** \u003cstrong\u003e\u003cstrong\u003eWITH_PROC_SCOPE_PTH=yes SKIP_DNS_CHECK=yes BUILD_OPTIMIZED=yes\u003c/strong\u003e install clean\u003c/strong\u003e //(utf8我选择了这个，情况自己定)\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e#cp /usr/local/share/mysql/my-medium.cnf /etc/my.cnf\n#rehash\u003c/strong\u003e\n!!!—–WITH_CHARSET=utf8(我选择了这个，情况自己定，可以使用gbk)\n\u003cstrong\u003e# mysql_install_db\u003c/strong\u003e ##初始化mysql,如果在命令行后面添加上 –user=mysql 的话，会失败，不清楚什么原因\u003c/p\u003e\n\u003cp\u003e#\u003cstrong\u003echown -R mysql:mysql /var/db/mysql\u003c/strong\u003e ##目录权 …\u003c/p\u003e"

"\u003cp\u003eExplain虽然是大家常用的分析mysql优化的办法，但对于系统级别内容的消耗资源信息就无能为力了．这时需要用到Mysql中的Profiling(程序剖析) 功能．参考：\u003c/p\u003e\n\u003cp\u003eEXPLAIN tbl_name or EXPLAIN SELECT select_options\u003c/p\u003e\n\u003cp\u003eEXPLAIN tbl_name是DESC[RIBE] tbl_name或SHOW COLUMNS FROM tbl_name的一个同义词。\u003c/p\u003e\n\u003cp\u003e当你在一条SELECT语句前放上关键词EXPLAIN，MySQL解释它将如何处理SELECT，提供有关表如何联结和以什么次序联结的信息。\u003c/p\u003e\n\u003cp\u003e借助于EXPLAIN，你可以知道\n1)你什么时候必须为表加入索引以得到一个使用索引找到记录的更快的SELECT。\n2)你也能知道优化器是否以一个最佳次序联结表。为了强制优化器对一个SELECT语句使用一个特定联结次序，增加一个STRAIGHT_JOIN子句。\u003c/p\u003e\n\u003cp\u003e对于非简单的联结，EXPLAIN为用于SELECT语句中的每个表返回一行信息。表以他们将被读入的顺序被列出。\nMySQL用一边扫描多次联结的方式解决所有联结，这意味着MySQL 1)从第 …\u003c/p\u003e"

"\u003cp\u003eMYSQL的优化是非常重要的。其他最常用也最需要优化的就是limit。mysql的limit给分页带来了极大的方便，但数据量一大的时候，limit的性能就急剧下降。\u003c/p\u003e\n\u003cp\u003e同样是取10条数据\u003c/p\u003e\n\u003cp\u003eselect * from yanxue8_visit limit 10000,10 和\u003c/p\u003e\n\u003cp\u003eselect * from yanxue8_visit limit 0,10\u003c/p\u003e\n\u003cp\u003e就不是一个数量级别的。\u003c/p\u003e\n\u003cp\u003e网上也很多关于limit的五条优化准则，都是翻译自mysql手册，虽然正确但不实用。今天发现一篇文章写了些关于limit优化的，很不错。\u003c/p\u003e\n\u003cp\u003e文中不是直接使用limit，而是首先获取到offset的id然后直接使用limit size来获取数据。根据他的数据，明显要好于直接使用limit。这里我具体使用数据分两种情况进行测试。（测试环境win2033+p4双核 (3GHZ) +4G内存 mysql 5.0.19）\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e1、offset比较小的时候。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eselect * from yanxue8_visit limit 10,10\u003c/p\u003e\n\u003cp\u003e多次运行，时间保持在0.0004-0.0005之间\u003c/p\u003e\n\u003cp\u003eSelect * From …\u003c/p\u003e"

"\u003cp\u003e使用PHP实现的程序.花了一个下午去完成…\u003c/p\u003e\n\u003cp\u003e只是做出来让大家参考一下…献丑了….\u003c/p\u003e\n\u003cp\u003e程序思路:\u003c/p\u003e\n\u003cp\u003e一\\与MYSQL数据库结合.先在MYSQL数据库另起一个库.记录数据库的库名,对应的用户名,限制的大小.等…..\u003c/p\u003e\n\u003cp\u003e二\\系统检测数据库大小,然后对比记录着的资料.对比是否超过流量.如果超过流量就使用MYSQL的ROOT权.限制用户对该数据库的权限…(删除UPDATE\\INST..等)\u003c/p\u003e\n\u003cp\u003e三\\如果达到80%.就向管理员\\用户各发送一个EMAIL通知..\u003c/p\u003e\n\u003cp\u003e四\\前台程序控制数据库资料的整理…\u003c/p\u003e\n\u003cp\u003e系统分二个部份.\u003c/p\u003e\n\u003cp\u003e第一部份.是系统定时检测数据库大小,再根据检测结果与数据库资料.判断数据库是否超大….该部份操作需要有MYSQL高权限用户去完成(建议ROOT).用该文件需要定时运行.,但该文件可以放在网站访问不到的保密地方…\u003c/p\u003e\n\u003cp\u003e所有文件.打包下载.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://www.xingkong.biz/mysql_limit.zip\"\u003ehttp://www.xingkong.biz/mysql_limit.zip\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCODE:\u003c/strong\u003e[Copy to clipboard] //设置部分\u003c/p\u003e\n\u003cp\u003e$id=mysql_connect(‘localhost’,’user’,’password’);   //最好是使 …\u003c/p\u003e"

"\u003cp\u003e一、CREATE TABLE 方法\u003c/p\u003e\n\u003cp\u003e整表复制 # create table 新表 select * from 旧表;\u003c/p\u003e\n\u003cp\u003e结构复制 # create table 新表 select * from 旧表 where 1\u0026lt;\u0026gt;1;\u003c/p\u003e\n\u003cp\u003e二、INSERT INTO 方法\u003c/p\u003e\n\u003cp\u003e得到建表语句 # show create table 旧表;\u003c/p\u003e\n\u003cp\u003e新建表\u003c/p\u003e\n\u003cp\u003e复制数据到新表 # insert into 新表 select * from 旧表;\u003c/p\u003e"

"\u003cp\u003eshow   index   from   表名;\u003c/p\u003e"

"\u003cp\u003e\u003cstrong\u003eMysql基础优化第一讲\u003c/strong\u003e      讲师：陈书艺\u003c/p\u003e\n\u003cp\u003e参数的调整可以通过修改 /etc/my.cnf 文件并重启 MySQL 实现。这是一个比较谨慎的工作，上面的结果也仅仅是我的一些看法，你可以根据你自己主机的硬件情况（特别是内存大小）进一步修改。\u003c/p\u003e\n\u003cp\u003e同时在线访问量继续增大 对于1G内存的服务器明显感觉到吃力严重时甚至每天都会死机 或者时不时的服务器卡一下 这个问题曾经困扰了我半个多月MySQL使用是很具伸缩性的算法，因此你通常能用很少的内存运行或给MySQL更多的被存以得到更好的性能。\u003c/p\u003e\n\u003cp\u003e安装好mysql后，配制文件应该在/usr/local/mysql/share/mysql目录中，配制文件有几个，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的网站和不同配制的服务器环境，当然需要有不同的配制文件了。\u003c/p\u003e\n\u003cp\u003e一般的情况下，my-medium.cnf这个配制文件就能满足我们的大多需要；一般我们会把配置文件拷贝到/etc/my.cnf 只需要修改这个配置文件就可以了，使用mysqladmin variables …\u003c/p\u003e"

"\u003cp\u003e本文主要讲述了如何加速动态网站的\u003ca href=\"http://www.phpchina.com/viewnews_11670.html\"\u003eMySQL\u003c/a\u003e索引分析和优化。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e一、什么是索引？\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。\u003c/p\u003e\n\u003cp\u003e假设我们创建了一个名为people的表：\u003c/p\u003e\n\u003cp\u003eCreate TABLE people ( peopleid SMALLINT NOT NULL,\u003c/p\u003e\n\u003cp\u003ename CHAR(50) NOT NULL );\u003c/p\u003e\n\u003cp\u003e然后，我们完全随机把1000个不同name值插入到people表。在数据文件中name列没有任何明确的次序。如果我们创建了name列的索引，MySQL将在索引中排序name列,对于索引中的每一项，MySQL在内部为它保存一个数据文件中实际记录所在位置的“指针”。因此，如果我们要查找name等于“Mike”记录 …\u003c/p\u003e"