MySQL简单介绍——换个角度认识MySQL

1、InnoDB存储引擎

Mysql版本>=5.5 默认的存储引擎，MySQL推荐使用的存储引擎。支持事务，行级锁定，外键约束。事务安全型存储引擎。更加注重数据的完整性和安全性。

存储格式 : 数据，索引集中存储，存储于同一个表空间文件中。

InnoDB的行锁模式及其加锁方法： InnoDB中有以下两种类型的行锁：共享锁（读锁： 允许事务对一条行数据进行读取）和 互斥锁（写锁： 允许事务对一条行数据进行删除或更新）， 对于update，insert，delete语句，InnoDB会自动给设计的数据集加互斥锁，对于普通的select语句，InnoDB不会加任何锁。

InnoDB行锁的实现方式： InnoDB行锁是通过给索引上的索引项加锁来实现的，如果没有索引，InnoDB将通过隐藏的聚簇索引来对记录加锁。InnoDB这种行锁实现特点意味着：如果不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，实际效果跟表锁一样。

（1）在不通过索引条件查询时，InnoDB会锁定表中的所有记录。

（2）Mysql的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果使用相同的索引键，是会出现冲突的。

（3）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，但都是通过行锁来对数据加锁。

优点：

1、支持事务处理、ACID事务特性；

2、实现了SQL标准的四种隔离级别（ 原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（Isolation ）和持续性（Durability ））；

3、支持行级锁和外键约束；

4、可以利用事务日志进行数据恢复。

5、锁级别为行锁，行锁优点是适用于高并发的频繁表修改，高并发是性能优于 MyISAM。缺点是系统消耗较大。

6、索引不仅缓存自身，也缓存数据，相比 MyISAM 需要更大的内存。

缺点：

因为它没有保存表的行数，当使用COUNT统计时会扫描全表。

使用场景：

(1)可靠性要求比较高，或者要求事务；(2)表更新和查询都相当的频繁，并且表锁定的机会比较大的情况。

2、 MyISAM存储引擎

MySQL<= 5.5 MySQL默认的存储引擎。ISAM：Indexed Sequential Access Method(索引顺序存取方法)的缩写，是一种文件系统。擅长与处理，高速读与写。

功能：

（1）支持数据压缩存储,但压缩后的表变成了只读表，不可写；如果需要更新数据，则需要先解压后更新。

（2）支持表级锁定，不支持高并发；

（3）支持并发插入。写 *** 作中的插入 *** 作，不会阻塞读 *** 作（其他 *** 作）；

优点：

1.高性能读取；

2.因为它保存了表的行数，当使用COUNT统计时不会扫描全表；

缺点：

1、锁级别为表锁，表锁优点是开销小，加锁快；缺点是锁粒度大，发生锁冲动概率较高，容纳并发能力低，这个引擎适合查询为主的业务。

2、此引擎不支持事务，也不支持外键。

3、INSERT和UPDATE *** 作需要锁定整个表；

使用场景：

(1)做很多count 的计算；(2)插入不频繁，查询非常频繁；(3)没有事务。

InnoDB和MyISAM一些细节上的差别：

1、InnoDB不支持FULLTEXT类型的索引，MySQL5.6之后已经支持（实验性）。

2、InnoDB中不保存表的 具体行数，也就是说，执行select count() from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count()语句包含 where条件时，两种表的 *** 作是一样的。

3、对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。

4、DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。

5、LOAD TABLE FROM MASTER *** 作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。

6、另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表。

1．索引概述

利用关键字，就是记录的部分数据（某个字段，某些字段，某个字段的一部分），建立与记录位置的对应关系，就是索引。索引的关键字一定是排序的。索引本质上是表字段的有序子集，它是提高查询速度最有效的方法。一个没有建立任何索引的表，就相当于一本没有目录的书，在每次查询时就会进行全表扫描，这样会导致查询效率极低、速度也极慢。如果建立索引，那么就好比一本添加的目录，通过目录的指引，迅速翻阅到指定的章节，提升的查询性能，节约了查询资源。

2．索引种类

从索引的定义方式和用途中来看：主键索引，唯一索引，普通索引，全文索引。

无论任何类型，都是通过建立关键字与位置的对应关系来实现的。索引是通过关键字找对应的记录的地址。

以上类型的差异：对索引关键字的要求不同。

关键字：记录的部分数据（某个字段，某些字段，某个字段的一部分）。

普通索引,index：对关键字没有要求。

唯一索引,unique index：要求关键字不能重复。同时增加唯一约束。

主键索引,primary key：要求关键字不能重复，也不能为NULL。同时增加主键约束。

全文索引,fulltext key：关键字的来源不是所有字段的数据，而是从字段中提取的特别关键词。

PS：这里主键索引和唯一索引的区别在于：主键索引不能为空值，唯一索引允许空值；主键索引在一张表内只能创建一个，唯一索引可以创建多个。主键索引肯定是唯一索引，但唯一索引不一定是主键索引。

3.索引原则

如果索引不遵循使用原则，则可能导致索引无效。

（1）列独立

如果需要某个字段上使用索引，则需要在字段参与的表达中，保证字段独立在一侧。否则索引不会用到索引, 例如这条sql就不会用到索引:select * from A where id+1=10

（2）左原则

Like：匹配模式必须要左边确定不能以通配符开头。例如:select * from A where name like '%小明%' ，不会用到索引，而select * from A where name like '小明%' 就可以用到索引（name字段有建立索引），如果业务上需要用到'%小明%'这种方式,有两种方法:1.可以考虑全文索引,但mysql的全文索引不支持中文；2.只查询索引列或主键列,例如:select name from A where name like '%小明%' 或 select id from A where name like '%小明%' 或 select id,name from A where name like '%小明%' 这三种情况都会用到name的索引

复合索引：一个索引关联多个字段，仅仅针对左边字段有效果，添加复合索引时，第一个字段很重要，只有包含第一个字段作为查询条件的情况才会使用复合索引(必须用到建索引时选择的第一个字段作为查询条件,其他字段的顺序无关),而且查询条件只能出现and拼接,不能用or,否则则无法使用索引.

（3）OR的使用

必须要保证 OR 两端的条件都存在可以用的索引，该查询才可以使用索引。

（4）MySQL智能选择

即使满足了上面说原则，MySQL也能弃用索引，例如：select * from A where id >1这里弃用索引的主要原因：查询即使使用索引，会导致出现大量的随机IO，相对于从数据记录的第一条遍历到最后一条的顺序IO开销，还要大。

4.索引的使用场景

（1）索引检索：检索数据时使用索引。

（2）索引排序: 如果order by 排序需要的字段上存在索引，则可能使用到索引。

（3）索引覆盖: 索引拥有的关键字内容，覆盖了查询所需要的全部数据，此时，就不需要在数据区获取数据，仅仅在索引区即可。覆盖就是直接在索引区获取内容，而不需要在数据区获取。例如: select name from A where name like '小明%'

建立索引索引时，不能仅仅考虑where检索，同时考虑其他的使用场景。（在所有的where字段上增加索引，就是不合理的）

5.前缀索引

前缀索引是建立索引关键字一种方案。通常会使用字段的整体作为索引关键字。有时，即使使用字段前部分数据，也可以去识别某些记录。就比如一个班级里，我要找王xx，假如姓王的只有1个人，那么就可以建一个关键字为'王'的前缀索引。语法：Index `index_name` (`index_field`(N))使用index_name前N个字符建立的索引。

6.索引失效

（1） 应尽量避免在 where 子句中使用 != 或 > *** 作符，否则将引擎放弃使用索引而进行全表扫描；

（2） 应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描；

（3） 应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描；

（4）应尽量避免在 where 子句中对字段进行表达式 *** 作，这将导致引擎放弃使用索引而进行全表扫描；如select id from t where num/2 = 100；

（5） 应尽量避免在where子句中对字段进行函数 *** 作，这将导致引擎放弃使用索引而进行全表扫描；如：select id from t where substring(name,1,3) = ’abc’ ；

（6）应尽量避免在where子句中对字段进行类型转换，这将导致引擎放弃使用索引而进行全表扫描； 如果列类型是字符串，那一定要在条件中将数据使用引号引用起来,如select id from t where id = 1；如果id字段在表设计中是varchar类型，那么即使id列上存的是数字，在查询时也一定要用varchar去匹配，sql应改为select id from t where id = '1'；

（7）应尽量避免在where子句中单独引用复合索引里非第一位置的索引；

join 的两种算法：BNL 和 NLJ

NLJ（Nested Loop Join）嵌套循环算法；以如下 SQL 为例：

select * from t1 join t2 on t1.a=t2.a

SQL 执行时内部流程是这样的：

1. 先从 t1（假设这里 t1 被选为驱动表）中取出一行数据 X；

2. 从 X 中取出关联字段 a 值，去 t2 中进行查找，满足条件的行取出；

3. 重复1、2步骤，直到表 t1 最后一行循环结束。

这就是一个嵌套循环的过程，如果在被驱动表上查找数据时可以使用索引，总的对比计算次数等于驱动表满足 where 条件的行数。假设这里 t1、t2都是1万行，则只需要 1万次计算，这里用到的是Index Nested-Loops Join（INLJ，基于索引的嵌套循环联接）。

如果 t1、t2 的 a 字段都没有索引，还按照上述的嵌套循环流程查找数据呢？每次在被驱动表上查找数据时都是一次全表扫描，要做1万次全表扫描，扫描行数等于 1万+1万*1万，这个效率很低，如果表行数更多，扫描行数动辄几百亿，所以优化器肯定不会使用这样的算法，而是选择 BNL 算法；

BNLJ（Block Nested Loop Join）块嵌套循环算法；

1. 把 t1 表（假设这里 t1 被选为驱动表）满足条件的数据全部取出放到线程的 join buffer 中；

2. 每次取 t2 表一行数据，去 joinbuffer 中进行查找，满足条件的行取出，直到表 t2 最后一行循环结束。

这个算法下，执行计划的 Extra 中会出现 Using join buffer(Block Nested Loop)，t1、t2 都做了一次全表扫描，总的扫描行数等于 1万+1万。但是由于 joinbuffer 维护的是一个无序数组，每次在 joinbuffer 中查找都要遍历所有行，总的内存计算次数等于1万*1万。另外如果 joinbuffer 不够大放不下驱动表的数据，则要分多次执行上面的流程，会导致被驱动表也做多次全表扫描。

BNLJ相对于NLJ的优点在于，驱动层可以先将部分数据加载进buffer，这种方法的直接影响就是将大大减少内层循环的次数，提高join的效率。

例如：

如果内层循环有100条记录，外层循环也有100条记录，这样的话，每次外层循环先将10条记录放到buffer中，内层循环的100条记录每条与这个buffer中的10条记录进行匹配，只需要匹配内层循环总记录数次即可结束一次循环（在这里，即只需要匹配100次即可结束），然后将匹配成功的记录连接后放入结果集中，接着，外层循环继续向buffer中放入10条记录，同理进行匹配，并将成功的记录连接后放入结果集。后续循环以此类推，直到循环结束，将结果集发给client为止。

可以发现，若用NLJ，则需要100 * 100次才可结束，BNLJ则需要100 / block_size * 100 = 10 * 100次就可结束,大大减少了循环次数。

JOIN 按照功能大致分为如下三类：

JOIN、STRAIGHT_JOIN、INNER JOIN（内连接,或等值连接）：取得两个表中存在连接匹配关系的记录。

LEFT JOIN（左连接）：取得左表（table1）完全记录，即是右表（table2）并无对应匹配记录。

RIGHT JOIN（右连接）：与 LEFT JOIN 相反，取得右表（table2）完全记录，即是左表（table1）并无匹配对应记录。

注意：mysql不支持Full join,不过可以通过UNION 关键字来合并 LEFT JOIN 与 RIGHT JOIN来模拟FULL join。

mysql 多表连接查询方式，因为mysql只支持NLJ算法,所以如果是小表驱动大表则效率更高；反之则效率下降；因此mysql对内连接或等值连接的方式做了一个优化,会去判断join表的数据行大小,然后取数据行小的表为驱动表。

INNER JOIN、JOIN、WHERE等值连接和STRAIGHT_JOIN都能表示内连接，那平时如何选择呢？一般情况下用INNER JOIN、JOIN或者WHERE等值连接，因为MySQL 会按照"小表驱动大表的策略"进行优化。当出现需要排序时，才考虑用STRAIGHT_JOIN指定某张表为驱动表。

两表JOIN优化

a.当无order by条件时，根据实际情况，使用left/right/inner join即可，根据explain优化 ；

b.当有order by条件时，如select * from a inner join b where 1=1 and other condition order by a.col；使用explain解释语句；

1）如果第一行的驱动表为a，则效率会非常高，无需优化；

2）否则，因为只能对驱动表字段直接排序的缘故，会出现using temporary，所以此时需要使用STRAIGHT_JOIN明确a为驱动表，来达到使用a.col上index的优化目的；或者使用left join且Where条件中不含b的过滤条件，此时的结果集为a的全集，而STRAIGHT_JOIN为inner join且使用a作为驱动表。注：使用STRAIGHT_JOIN虽然不会using temporary，但也不是一定就能提高效率，如果a表数据远远超过b表，那么有可能使用STRAIGHT_JOIN时比原来的sql效率更低，所以怎么使用STRAIGHT_JOIN，还是要视情况而定。

在使用left join（或right join）时，应该清楚的知道以下几点：

(1). on与 where的执行顺序

ON 条件（“A LEFT JOIN B ON 条件表达式”中的ON）用来决定如何从 B 表中检索数据行。如果 B 表中没有任何一行数据匹配 ON 的条件,将会额外生成一行所有列为 NULL 的数据,在匹配阶段 WHERE 子句的条件都不会被使用。仅在匹配阶段完成以后，WHERE 子句条件才会被使用。它将从匹配阶段产生的数据中检索过滤。

所以我们要注意：在使用Left (right) join的时候，一定要在先给出尽可能多的匹配满足条件，减少Where的执行。

(2).注意ON 子句和 WHERE 子句的不同

即使右表的数据不满足ON后面的条件,也会在结果集拼接一条为NULL的数据行,但WHERE后面的条件不一样,右表不满足WHERE的条件,左表关联的数据也会被过滤掉。

(3).尽量避免子查询，而用join

往往性能这玩意儿，更多时候体现在数据量比较大的时候，此时，我们应该避免复杂的子查询。

（1）in 和 not in 要慎用，如：select id from t where num in(1,2,3)对于连续的数值，能用 between 就不要用 in：select id from t where num between 1 and 3很多时候用 exists 代替 in 是一个好的选择：select num from a where num in(select num from b)用下面的语句替换：select num from a where exists(select 1 from b where num=a.num)

（2）Update 语句，如果只更改1、2个字段，不要Update全部字段，否则频繁调用会引起明显的性能消耗，同时带来大量日志。

（3）join语句,MySQL里面的join是用小表去驱动大表,而由于MySQL join实现的原理就是做循环，比如left join就是对左边的数据进行循环去驱动右边的表,左边有m条记录匹配,右边有n条记录那么就是做m次循环,每次扫描n行数据,总扫面行数是m*n行数据。左边返回的结果集的大小就决定了循环的次数,故单纯的用小表去驱动大表不一定的正确的,小表的结果集可能也大于大表的结果集,所以写join的时候尽可能的先估计两张表的可能结果集,用小结果集去驱动大结果集.值得注意的是在使用left/right join的时候,从表的条件应写在on之后,主表应写在where之后.否则MySQL会当作普通的连表查询；

（4）select count(*) from table；这样不带任何条件的count会引起全表扫描，并且没有任何业务意义，是一定要杜绝的；

（5）select * from t 这种语句要尽量避免，使用具体的字段代替*，更有实际意义，需要什么字段就返回什么字段；

（6）数据量大的情况下，limit要慎用，因为使用limit m，n方式分页时，mysql每次都是查询前m+n条，然后舍弃前m条，所以m越大，偏移量越大，性能就越差。比如：select * from A limit 1000000,20这钟，查询效率就会非常低，当分页的页数大于一定的数量之后，就可以换种方式来分页：select * from A a join （select id from A limit 1000000，20） b on a.id=b.id

MySQL作为一种非常流行的关系型数据库，在信息系统开发中扮演着非常重要的角色，经常被用于后端数据存储，而MySQL本身又不提供非常便捷的客户端软件，因此出现了许许多多的第三方管理软件，下面我简单介绍几个，感兴趣的朋友可以自己下载尝试一下：

SQLyog

这是一个非常轻巧灵活的MySQL客户端软件，界面整洁、干净友好，大部分开发人员都应该听说或使用过，可以直接查看数据库目录结构，建库建表灵活，支持SQL脚本导入导出、数据备份恢复等常见功能，语法高亮、自动补全等也都非常不错，对于日常MySQL管理来说，是一个非常不错的工具：

Navicat

这也是一个非常不错的MySQL客户端管理软件，界面简洁、功能强大，基本使用方式和SQLyog差不多，可以直接手动建库建表、设计视图（包括字段类型、主外键关系、触发器等），支持数据库建模、SQL脚本导入导出、数据恢复和备份等常见功能，对于MySQL管理来说，也是一个非常不错的工具：

Workbench

这是MySQL官方自带的一个客户端软件，可以直接到官网下载安装，免费、跨平台，专门为MySQL量身定制，兼容性良好，支持数据库建模（ER模型、前向和反向工程）、数据迁移（低版本到高版本）、恢复与备份等常见功能，对于MySQL日常管理来说，也是一个非常不错的工具：

phpMyAdmin

这是一个专门为php开发人员设计的MySQL管理工具，基于Web浏览器运行，界面干净、整洁友好，可以很方便的查阅管理日常数据库，建库建表也非常容易，如果你是一个专业的php开发人员，那么phpMyAdmin就是一个非常不错的管理工具，缺点就是在数据的备份和恢复上不是很方便：

DataGrip

这是一个比较全能的数据库客户端软件，支持目前几乎所有的主流数据库，包括MySQL，Oracle，SQL Server等，界面友好、干净整洁，日常查询、建库建表、建模设计、备份恢复、数据迁移等，这个软件都能很好支持，语法高亮、自动补全等功能也都非常不错，对于数据库管理来说，也是一个非常不错的工具：

当然，还有许多其他MySQL客户端管理软件，像HeidiSQL，DBeaver等也都非常不错，这里就不一一介绍了，基本功能和前面的这5个软件差不多，只要你熟悉一下使用方式，很快就能掌握的。至于哪个好，哪个更优秀，这个也没有什么明确标准，只要适合自己就行，如果你非常熟悉MySQL的话，也可以使用命令行工具，效果是一样的，网上也有相关资料，感兴趣的话，可以搜一下，希望以上分享的内容能对你有所帮助吧，也欢迎大家评论、留言进行补充。

MySQL的管理维护工具非常多，除了系统自带的命令行管理工具之外，还有许多其他的图形化管理工具，这里我介绍几个经常使用的MySQL图形化管理工具，供大家参考。

1、phpMyAdmin

phpMyAdmin是最常用的MySQL维护工具，是一个用PHP开发的基于Web方式架构在网站主机上的Mysql管理工具，支持中文，管理数据库非常方便。不足之处在于对大数据库的备份和恢复不方便。

2、MySQLDumper

MySQLDumper使用PHP开发的MySQL数据库备份恢复程序，解决了使用PHP进行大数据库备份和恢复的问题，数百兆的数据库都可以方便的备份恢复，不用担心网速太慢导致中间中断的问题，非常方便易用。

这个软件是德国人开发的，还没有中文语言包。

3、Navicat

Navicat是一个桌面版MySQL数据库管理和开发工具。和微软SQLServer的管理器很像，易学易用。

Navicat使用图形化的用户界面，可以让用户使用和管理更为轻松。支持中文，有免费版本提供。

4、MySQL GUI Tools

MySQL GUI Tools是MySQL官方提供的图形化管理工具，功能很强大，值得推荐，可惜的是没有中文界面。

5、MySQL ODBC Connector

MySQL官方提供的ODBC接口程序，系统安装了这个程序之后，就可以通过ODBC来访问MySQL，这样就可以实现SQLServer、Access和MySQL之间的数据转换，还可以支持ASP访问MySQL数据库。

6、MySQL Workbench

MySQL Workbench是一个统一的可视化开发和管理平台，该平台提供了许多高级工具，可支持数据库建模和设计、查询开发和测试、服务器配置和监视、用户和安全管理、备份和恢复自动化、审计数据检查以及向导驱动的数据库迁移。

MySQL Workbench是MySQL AB发布的可视化的数据库设计软件，它的前身是 FabForce 公司的 DDesigner 4。

MySQL Workbench 为数据库管理员、程序开发者和系统规划师提供可视化设计、模型建立、以及数据库管理功能。

它包含了用于创建复杂的数据建模ER模型，正向和逆向数据库工程，也可以用于执行通常需要花费大量时间和需要的难以变更和管理的文档任务。MySQL工作台可在Windows，Linux和Mac上使用。

7、SQLyog

SQLyog 是一个易于使用的、快速而简洁的图形化管理MYSQL数据库的工具，它能够在任何地点有效地管理你的数据库。

SQLyog是业界著名的Webyog公司出品的一款简洁高效、功能强大的图形化MySQL数据库管理工具。使用SQLyog可以快速直观地让您从世界的任何角落通过网络来维护远端的MySQL数据库。

云时代，最好用的MySQL客户端工具推荐

MySQL是当今最受欢迎的关系型数据库。使用图形客户端（GUI）工具，可以大大帮助开发者提升SQL编写与SQL开发的效率。在云时代，企业越来越多的开始采用RDS MySQL，同时也还有部分本地IDC自建数据库，而在云端也会选择/尝试多个不同云厂商。“工欲善其事，必先利其器”，在这样的背景下，看看有哪些工具产品可供选择吧。

本文完整对比了12种MySQL图形客户端（GUI）工具，从产品体验、功能完整度、云适配、计费模式、OS兼容性等多个角度进行评估与分析，给出推荐。下面产品推荐与整体得分图，读者可根据自己的实际情况选择。

NineData：

是一款非常有特色的数据库SQL开发产品，对MySQL常用功能支持非常完整，包括智能的SQL补全、SQL执行历史、结果集编辑、数据对比、结构对比、数据迁移与复制等。它采用SaaS架构模式，用户不仅可以免费使用，而且无需下载安装，上手比较简单。NineData产品更新迭代比较敏捷，对于开发者的新需求响应比较迅速。另外，该产品在多云适配上是其重要的强项，支持多种连接和访问云数据库的方式，对阿里云、腾讯云、华为云、AWS等都有比较好的支持。另外，也适配国内比较流行的PolarDB、GaussDB、TDSQL等数据库。对于新用户NineData还会赠送两个示例数据库，供用户使用。另外，NineData还提供了企业级SQL开发能力，支持多用户管理、数据库访问权限控制、变更流程、SQL规范、SQL与 *** 作审计等内容，可以较好的解决企业内多人协作访问数据库的问题。

Navicat：

是一款来自香港的产品，约2000年左右发布，是一个老牌的商业化、闭源数据库管理软件，支持主流的Windows、Mac OS X以及Linux，最近两年开始支持订阅模式，个人使用价格约35美元/月，企业版约69美元/月（参考），国内购买为273元/月，有一定的价格门槛，但其使用体验也还不错，功能也比较完整，包括比较强大的SQL补全、导入导出、结果集编辑、E-R模型、数据对比、结构对比、数据迁移等，但有部分功能仅企业版才具备。Navicat的代码块功能做得比较强，可以非常方便自定义一些自己常用的SQL模板。

Workbench：

是最老牌的数据库管理工具了。最早由奥地利程序员Michael G. Zinner独立开发，之后Zinner于2003年加入了MySQL AB公司，并于2005年发布了最早的Workbench 5.0版本；2013年发布了，6.0版本；2018年，发布了8.0版本。整体上，该产品依旧随着MySQL的版本而持续更新，但是，更新节奏较慢，界面也非常“老”，并没有受到Oracle/MySQL的重视。Workbench支持主流的Windows、Mac OS X以及Linux，并且开放源代码。但因为界面架构比较长时间没有更新，所以使用的交互体验一般。因为是MySQL官方工具，功能支持是比较完整的，包括SQL补全、SQL历史、导入导出、结果集编辑、E-R模型、数据对比、结构对比、数据迁移等功能都具备。另外，也提供商业化的企业版，支持部分MySQL企业版的功能。

DBeaver：

是一个基于 Java 开发数据库管理工具，提供开源免费的版本。因为是基于Java的，所以也能够支持Windows、Linux、macOS 等 *** 作系统，其支持的数据库类型也比较多。同时也是因为基于Java，其在访问的不同的数据库版本时，有时候需要在线做一些驱动更新，需要访问GitHub的一些资源，而因为一些原因，这类更新经常失败，使其使用体验有一定打折。DBeaver也提供了基础的SQL补全、导入导出、结果集编辑等功能，但也有部分功能仅限于企业版（Pro版本）才提供，另外，软件似乎因为比较大的缘故，所以运行起来有点慢。

phpMyAdmin：

这是另一个老牌的开源免费MySQL访问工具了，在云时代之前，开发者经常需要自己搭建自己完整的开发环境（例如“LAMP”）时，该软件还比较流行。从名字可以看出来，这是一个PHP的Web-Based的MySQL访问工具，所以需要使用并不是很方便，需要构建自己的Web服务器和PHP运行环境。一般来说，现在的开发者也并不会这么去做。另外，phpMyAdmin一直没有商业化，主要靠捐赠和赞助的方式在运转（参考，有意思的是Navicat也在赞助列表，而且是唯一的白金赞助商），整体上，phpMyAdmin其迭代速度非常慢，功能支持也很有限，但是如果是简单、基础的使用，是没有问题的。但，如果是日常开发使用，并不是很推荐。

dbForge：

dbForge是devart的核心产品，最早主要是支持SQL Server数据库，最近几年也发布了对MySQL数据库的支持，也是一个商业化收费软件，产品可以下载试用一段时间。根据使用经验来看，体验还是非常不错的，功能也非常完整。但是，仅支持Windows版本，标准版费用为199美元/年，起步价也并不便宜。

SQLYOG：

SQLyog更多的是专注于数据库的管理，包括性能、监控、优化等方面，也提供基础SQL编辑功能，所以在早期，其在DBA群体中比较受欢迎，但是在整体的开发者中，使用比率并不高。虽然，提供开源的社区版本，但是当前，公司主要在推广其商业版本。另外，在云时代对于监控与实例管理方面的诉求在降低，在SQL开发与云适配上需求更强。从这个角度来看，并不是很推荐这个这个产品。此外，该软件仅支持Windows系统。最近几年这个产品发展比较缓慢，而且SQL开发功能也不再是主推的功能，所以也并不是特别推荐。

HeidiSQL：

HeidiSQL也是一个发展了很长时间的MySQL客户端，使用Delphi构建，所以整体上，有非常好的Windows使用体验。但是不能支持macOS或者Linux。因为发展时间比较长，功能也比较完整。新增了部分对于云产品的适配，例如，如果类型选择的是AWS RDS，那么在kill连接的时候会使用特定的存储过程进行kill。

阿里云DMS：

因为阿里云在国内市占率非常高，所以，阿里云DMS也是一个使用比较广，但是也因为其为阿里云的产品，所以其作为MySQL管理工具并不是非常有名。DMS比较完整的支持MySQL日常SQL开发相关的工作，其功能矩阵也比较完整，可以完成日常的开发工作。DMS对于阿里云数据库的适配自然是非常好，使用也比较便利。但，其对于其他云数据库（诸如腾讯、华为、AWS）的支持就比较有限，而且似乎也并不会在这方面做任何的投入。另外，DMS最近一年的产品大方向主要是在于"一站式的数据管理"，所以新增了数据资产、数据开发任务编排等功能。不再是一个SQL开发工具。

BeeKeeper Studio：

Beekeeper目前是由一个由个人开发的MySQL GUI软件。界面简洁现代，支持比较基础的SQL开发功能，包括了SQL窗口、创建表等能力，同时有非常好的平台兼容性。向用户提供免费的功能有限的社区版，完整版是收费的，最低价格为19美元。

DbVisualizer：

DbVisualizer发展时间也比较长了，支持的数据库种类也非常多，底层是基于Java构建的，有不错的平台兼容性，支持Windows / Linux / macOS，在市场也获得不错认可。不过，该软件仅支持英语，并没有对应的中文支持。

小结

通过Wine等方式支持的OS平台，这里并没有考虑，因为根据经验来看，大多数情况下，稳定性都不太好。另外，市面上也还有一些产品超过两年未更新，这里就不再介绍了，例如MyDB Studio；也有部分软件平台属性太强，例如Sequel Pro仅支持Mac，这里也没有介绍。总体上，打分有较强的主观性，所以仅供参考。

---