如何用SQLyog来分析MySQL数据库

用SQLyog来分析MySQL数据库 SOLyog的下载 安装以及使用很简单 我去了相关网站下载 它只有 K字节大小 它把两个文件(一个可执行文件 exe和一个动态链接库文件 dll)安装到C:\Program Files\SQLyog路径下 然后运行可执行文件

安装后没有必要再访问该网站了 我访问该网站是得到了一个消息 说它的域名没有设置(configured) 登记 或正在建设中 我不清楚这个问题是暂时的还是一直是这样 该软件是免费的 并且没有标志广告(banner ads) 所以它可能是一个特定的尚未最终定型的商业模型 最终可能还是要负费的

数据库 表格(table)和列树(column tree)

该程序一启动就开始询问我的登录到MySOL服务器的口令 我只需要输入我的服务器名字 用户id和登录密码 所有其它的设置都是正确的默认值 然后(当我开始其它事务 重启几次 睡了一会之后) 我重新运行该程序 这时只需要再次输入我的登录密码 该程序没有保存密码的选项 你可以认为这是该程序的一个bug 也可以说是程序的保密特性

一旦你登录之后 界面就是很值得注意 MySOL服务器上所有的数据库都显示在一个树型控件上 你只能访问你在登录时授权的那个数据库 如果你点开代表授权给你的那个数据库的树型结构 你就可以看到一系列代表表格的节点 点开表格节点后 你就可以看到一系列显示字段名的节点和另一个代表索引的节点集合

索引界面绝对是个好东东 这样你就可以CRUD查询索引和关键字了 这相对前端数据库如Microsoft Access来说是个提高 如果考虑到MySOL刚刚开始提供对主(primary)和非相关(foreign)关键字关系的支持 本程序这部分的设计是很成熟的 在右下方的面板上 有四个标签页 即 结果(Result) 消息(Message) 对象(Object)和历史(History)

有什么缺点？

我试图发现该程序的缺点 不过只发现了一个 如果你在Win Dependency Walker下运行程序的 exe文件 你会发现它引用了DLG dll文件 而DLG dll又轮流引用AppHelp 实事上 CommDlg调用AppHelp 而当AppHelp没有请求函数时 CommDlg这么做根本就是浪费资源

过于简单？

在SQLyog FAQ上 有一种观点认为该软件没有正式归档的必要 当然 FAQ(常见问题解答)本身就是一种归档 SQLyog的界面非常直观 我建议你打印一份MySOL文档(包括SQL特殊语法扩展) 我就是这么做的 它只用了一个半英寸的活页封面

最后一步？

FAQ还让人想到一个让人耳朵起了老茧却又是正确的Occam s Razor准则——一切超出必要的复杂性都是没有必要的 我之所以到处 推销 这个工具 就是因为它可以为我们提供一个可以管理MySOL服务器上许多数据库的 简单的 图形化的界面 它的速度极快 并且它的拷贝很小(可以放在一张软盘上)

lishixinzhi/Article/program/SQL/201404/30537

mysql数据库有undo空间

5种mysql做可靠性分析的方案：

1．MySQL Clustering(ndb-cluster stogare)

简介：

MySQL公司以存储引擎方式提供的高可靠性方案，是事务安全的，实时复制数据，可用于需要高可靠性及负载均衡的场合。该方案至少需要三个节点服务器才能达到较好的效果。

成本：

节点服务器对RAM的需求很大，与数据库大小呈线性比例；

最好使用千兆以太网络；

还需要使用Dolphin公司提供的昂贵的SCI卡。

优点：

可用于负载均衡场合；

可用于高可靠性场合；

高伸缩性；

真正的数据库冗余；

容易维护。

缺点：

随着数据库的变大，对RAM的需求变得更大，因此成本很高；

速度：

几乎 比典型的单独服务器（无千兆以太网，无SCI卡，存储引擎相关的限制少）慢10倍。

应用场合：

冗余，高可靠性，负载均衡

2. MySQL / GFS-GNBD/ HA (Active/Passive)

简介：

如果多个MySQL服务器使用共享硬盘作为数据存储，此方案如何？

GFS/GNBD可以提供所需的共享硬盘。

GFS是事务安全的文件系统。同一时刻你可以让一个MySQL使用共享数据。

成本：

最多n台高性能服务器的成本，其中一个激活的，其他作为备份服务器。

优点：

高可靠性

某种程度的冗余

按照高可靠性进行伸缩

缺点：

没有负载均衡

没有保证的冗余

无法对写 *** 作进行伸缩

速度：

单独服务器的2倍。对读 *** 作支持得较好。

应用场合：

需要高可靠性的、读 *** 作密集型的应用

3. MySQL / DRBD / HA (Active/Passive)

简介：

如果多个MySQL服务器使用共享硬盘作为数据存储，此方案如何？

DRBD可以提供这样的共享硬盘。DRBD可以被设置成事务安全的。

同一时刻你可以让一个MySQL使用共享数据。

成本：

最多n台高性能服务器的成本，其中一个激活的，而其他则作为备份服务器。

优点：

高可靠性；

一定程度的冗余；

以高可靠性名义来看是可伸缩的。

缺点：

没有负载均衡

没有保证的冗余

在写负载方面没有伸缩性

速度：

在读写方面相当于单独服务器

应用场合

需要高可靠性、读 *** 作密集型的应用

4. MySQL Write Master / Multiple MySQL Read Slaves (Active/Active)

简介：

考虑不同的读、写DB数据库连接的情况。可以使用一台主服务器用于写 *** 作，而采用n台从服务器用于读 *** 作。

成本：

最多1台高性能写服务器，n台读服务器的成本

优点:

读 *** 作的高可靠性；

读 *** 作的负载均衡；

在读 *** 作负载均衡方面是可伸缩的。

缺点：

无写 *** 作的高可靠性；

无写 *** 作的负载均衡；

在写 *** 作方面无伸缩性；

速度：

同单独服务器；在读 *** 作方面支持得较好

应用场合

读 *** 作密集型的、需要高可靠性和负载均衡的应用。

5. Standalone MySQL Servers(Functionally separated) (Active)

多台功能分离的单独服务器，没有高可靠性、负载均衡能力，明显缺点太多，不予考虑。

数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷.

1. 优化一览图

2. 优化

笔者将优化分为了两大类,软优化和硬优化,软优化一般是 *** 作数据库即可,而硬优化则是 *** 作服务器硬件及参数设置.

2.1 软优化

2.1.1 查询语句优化

1.首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息.

2.例:

显示:

其中会显示索引和查询数据读取数据条数等信息.

2.1.2 优化子查询

在MySQL中,尽量使用JOIN来代替子查询.因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高.

2.1.3 使用索引

索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者<MySQL数据库索引>一文,介绍比较详细,此处记录使用索引的三大注意事项:

2.1.4 分解表

对于字段较多的表,如果某些字段使用频率较低,此时应当,将其分离出来从而形成新的表,

2.1.5 中间表

对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时.

2.1.6 增加冗余字段

类似于创建中间表,增加冗余也是为了减少连接查询.

2.1.7 分析表,,检查表,优化表

分析表主要是分析表中关键字的分布,检查表主要是检查表中是否存在错误,优化表主要是消除删除或更新造成的表空间浪费.

1. 分析表: 使用 ANALYZE 关键字,如ANALYZE TABLE user

2. 检查表: 使用 CHECK关键字,如CHECK TABLE user [option]

option 只对MyISAM有效,共五个参数值:

3. 优化表:使用OPTIMIZE关键字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user

LOCAL|NO_WRITE_TO_BINLOG都是表示不写入日志.,优化表只对VARCHAR,BLOB和TEXT有效,通过OPTIMIZE TABLE语句可以消除文件碎片,在执行过程中会加上只读锁.

2.2 硬优化

2.2.1 硬件三件套

1.配置多核心和频率高的cpu,多核心可以执行多个线程.

2.配置大内存,提高内存,即可提高缓存区容量,因此能减少磁盘I/O时间,从而提高响应速度.

3.配置高速磁盘或合理分布磁盘:高速磁盘提高I/O,分布磁盘能提高并行 *** 作的能力.

2.2.2 优化数据库参数

优化数据库参数可以提高资源利用率,从而提高MySQL服务器性能.MySQL服务的配置参数都在my.cnf或my.ini,下面列出性能影响较大的几个参数.

2.2.3 分库分表

因为数据库压力过大，首先一个问题就是高峰期系统性能可能会降低，因为数据库负载过高对性能会有影响。另外一个，压力过大把你的数据库给搞挂了怎么办？所以此时你必须得对系统做分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这时作为主库承载写入请求。然后每个主库都挂载至少一个从库，由从库来承载读请求。

2.2.4 缓存集群

如果用户量越来越大，此时你可以不停的加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。然后数据库层面如果写入并发越来越高，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库。但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的，所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。如果你就是简单的不停的加机器，其实是不对的。所以在高并发架构里通常都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。所以单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。所以你完全可以根据系统的业务特性，对那种写少读多的请求，引入缓存集群。具体来说，就是在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。

一个完整而复杂的高并发系统架构中，一定会包含：各种复杂的自研基础架构系统。各种精妙的架构设计.因此一篇小文顶多具有抛砖引玉的效果,但是数据库优化的思想差不多就这些了.

---