如何用SQLyog来分析MySQL数据库

如何用SQLyog来分析MySQL数据库,第1张

用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

执行顺序:

适用结构相同的表联结成一张大表

内连接:返回两个表共同的行

左连接:以表 1 为基础,匹配表 2 的相同行

右连接:以表 2 为基础,匹配表 1 的相同行

全连接:返回全部数据,可以理解为左连接和右连接的结合

mysql 没有全连接

常用于组内排序,具体写法如下

窗口函数可以用 rank 相关函数或者聚合函数

当前日期+时间(date + time)函数:now()

当前时间戳函数:current_timestamp()

日期或时间转换为字符串 函数:date_format(date,format), time_format(time,format)

lower(str):将字符串参数值转换为全小写字母后返回

upper(str):将字符串参数值转换为全大写字母后返回

concat(str1, str2,...):将多个字符串参数首尾相连后返回

concat_ws(separator,str1,str2,...):将多个字符串参数以给定的分隔符 separator 首尾相连后返回

substr(str,pos):截取从 pos 位置开始到最后的所有 str 字符串

substr(str, pos, len):截取 str 字符串,从 pos 位置开始的 len 个字符

length(str):返回字符串的存储长度

char_length(str):返回字符串中的字符个数

format(X,D,locale):以格式 ‘#,###,###.##’ 格式化数字 X,D 指定小数位数,locale 指定国家语言(默认的 locale 为 en_US)

left(str, len):返回最左边的len长度的子串

right(str, len):返回最右边的len长度的子串

ltrim(str),rtrim(str):去掉字符串的左边或右边的空格

repeat(str, count):将字符串 str 重复 count 次后返回

reverse(str):将字符串 str 反转后返回

通俗易懂的学会:SQL窗口函数

mysql format时间格式化说明

MySQL常用字符串函数

一、MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句\x0d\x0a\x0d\x0a1,slow_query_log\x0d\x0a这个参数设置为ON,可以捕获执行时间超过一定数值的SQL语句。\x0d\x0a\x0d\x0a2,long_query_time\x0d\x0a当SQL语句执行时间超过此数值时,就会被记录到日志中,建议设置为1或者更短。\x0d\x0a\x0d\x0a3,slow_query_log_file\x0d\x0a记录日志的文件名。\x0d\x0a\x0d\x0a4,log_queries_not_using_indexes\x0d\x0a这个参数设置为ON,可以捕获到所有未使用索引的SQL语句,尽管这个SQL语句有可能执行得挺快。\x0d\x0a\x0d\x0a二、检测mysql中sql语句的效率的方法\x0d\x0a\x0d\x0a1、通过查询日志\x0d\x0a(1)、Windows下开启MySQL慢查询\x0d\x0aMySQL在Windows系统中的配置文件一般是是my.ini找到[mysqld]下面加上\x0d\x0a代码如下\x0d\x0alog-slow-queries = F:/MySQL/log/mysqlslowquery。log\x0d\x0along_query_time = 2\x0d\x0a\x0d\x0a(2)、Linux下启用MySQL慢查询\x0d\x0aMySQL在Windows系统中的配置文件一般是是my.cnf找到[mysqld]下面加上\x0d\x0a代码如下\x0d\x0alog-slow-queries=/data/mysqldata/slowquery。log\x0d\x0along_query_time=2\x0d\x0a说明\x0d\x0alog-slow-queries = F:/MySQL/log/mysqlslowquery。\x0d\x0a为慢查询日志存放的位置,一般这个目录要有MySQL的运行帐号的可写权限,一般都将这个目录设置为MySQL的数据存放目录;\x0d\x0along_query_time=2中的2表示查询超过两秒才记录;\x0d\x0a\x0d\x0a2.show processlist 命令\x0d\x0a\x0d\x0aSHOW PROCESSLIST显示哪些线程正在运行。您也可以使用mysqladmin processlist语句得到此信息。\x0d\x0a各列的含义和用途:\x0d\x0aID列\x0d\x0a一个标识,你要kill一个语句的时候很有用,用命令杀掉此查询 /*/mysqladmin kill 进程号。\x0d\x0auser列\x0d\x0a显示单前用户,如果不是root,这个命令就只显示你权限范围内的sql语句。\x0d\x0ahost列\x0d\x0a显示这个语句是从哪个ip的哪个端口上发出的。用于追踪出问题语句的用户。\x0d\x0adb列\x0d\x0a显示这个进程目前连接的是哪个数据库。\x0d\x0acommand列\x0d\x0a显示当前连接的执行的命令,一般就是休眠(sleep),查询(query),连接(connect)。\x0d\x0atime列\x0d\x0a此这个状态持续的时间,单位是秒。\x0d\x0astate列\x0d\x0a显示使用当前连接的sql语句的状态,很重要的列,后续会有所有的状态的描述,请注意,state只是语句执行中的某一个状态,一个 sql语句,以查询为例,可能需要经过copying to tmp table,Sorting result,Sending data等状态才可以完成\x0d\x0ainfo列\x0d\x0a显示这个sql语句,因为长度有限,所以长的sql语句就显示不全,但是一个判断问题语句的重要依据。\x0d\x0a\x0d\x0a这个命令中最关键的就是state列,mysql列出的状态主要有以下几种:\x0d\x0aChecking table\x0d\x0a 正在检查数据表(这是自动的)。\x0d\x0aClosing tables\x0d\x0a 正在将表中修改的数据刷新到磁盘中,同时正在关闭已经用完的表。这是一个很快的 *** 作,如果不是这样的话,就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中。\x0d\x0aConnect Out\x0d\x0a 复制从服务器正在连接主服务器。\x0d\x0a\x0d\x0aCopying to tmp table on disk\x0d\x0a 由于临时结果集大于tmp_table_size,正在将临时表从内存存储转为磁盘存储以此节省内存。\x0d\x0aCreating tmp table\x0d\x0a 正在创建临时表以存放部分查询结果。\x0d\x0adeleting from main table\x0d\x0a 服务器正在执行多表删除中的第一部分,刚删除第一个表。\x0d\x0adeleting from reference tables\x0d\x0a 服务器正在执行多表删除中的第二部分,正在删除其他表的记录。\x0d\x0a\x0d\x0aFlushing tables\x0d\x0a 正在执行FLUSH TABLES,等待其他线程关闭数据表。\x0d\x0aKilled\x0d\x0a 发送了一个kill请求给某线程,那么这个线程将会检查kill标志位,同时会放弃下一个kill请求。MySQL会在每次的主循环中检查kill标志位,不过有些情况下该线程可能会过一小段才能死掉。如果该线程程被其他线程锁住了,那么kill请求会在锁释放时马上生效。\x0d\x0aLocked\x0d\x0a 被其他查询锁住了。\x0d\x0aSending data\x0d\x0a 正在处理SELECT查询的记录,同时正在把结果发送给客户端。\x0d\x0a\x0d\x0aSorting for group\x0d\x0a 正在为GROUP BY做排序。\x0d\x0a Sorting for order\x0d\x0a 正在为ORDER BY做排序。\x0d\x0aOpening tables\x0d\x0a 这个过程应该会很快,除非受到其他因素的干扰。例如,在执ALTER TABLE或LOCK TABLE语句行完以前,数据表无法被其他线程打开。正尝试打开一个表。\x0d\x0aRemoving duplicates\x0d\x0a 正在执行一个SELECT DISTINCT方式的查询,但是MySQL无法在前一个阶段优化掉那些重复的记录。因此,MySQL需要再次去掉重复的记录,然后再把结果发送给客户端。\x0d\x0a\x0d\x0aReopen table\x0d\x0a 获得了对一个表的锁,但是必须在表结构修改之后才能获得这个锁。已经释放锁,关闭数据表,正尝试重新打开数据表。\x0d\x0aRepair by sorting\x0d\x0a 修复指令正在排序以创建索引。\x0d\x0aRepair with keycache\x0d\x0a 修复指令正在利用索引缓存一个一个地创建新索引。它会比Repair by sorting慢些。\x0d\x0aSearching rows for update\x0d\x0a 正在讲符合条件的记录找出来以备更新。它必须在UPDATE要修改相关的记录之前就完成了。\x0d\x0aSleeping\x0d\x0a 正在等待客户端发送新请求.\x0d\x0a\x0d\x0aSystem lock\x0d\x0a 正在等待取得一个外部的系统锁。如果当前没有运行多个mysqld服务器同时请求同一个表,那么可以通过增加--skip-external-locking参数来禁止外部系统锁。\x0d\x0aUpgrading lock\x0d\x0a INSERT DELAYED正在尝试取得一个锁表以插入新记录。\x0d\x0aUpdating\x0d\x0a 正在搜索匹配的记录,并且修改它们。\x0d\x0a\x0d\x0aUser Lock\x0d\x0a 正在等待GET_LOCK()。\x0d\x0aWaiting for tables\x0d\x0a 该线程得到通知,数据表结构已经被修改了,需要重新打开数据表以取得新的结构。然后,为了能的重新打开数据表,必须等到所有其他线程关闭这个表。以下几种情况下会产生这个通知:FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。\x0d\x0awaiting for handler insert\x0d\x0a INSERT DELAYED已经处理完了所有待处理的插入 *** 作,正在等待新的请求。\x0d\x0a 大部分状态对应很快的 *** 作,只要有一个线程保持同一个状态好几秒钟,那么可能是有问题发生了,需要检查一下。\x0d\x0a 还有其他的状态没在上面中列出来,不过它们大部分只是在查看服务器是否有存在错误是才用得着。\x0d\x0a\x0d\x0a例如如图:\x0d\x0a\x0d\x0a3、explain来了解SQL执行的状态\x0d\x0aexplain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。\x0d\x0a使用方法,在select语句前加上explain就可以了:\x0d\x0a例如:\x0d\x0aexplain select surname,first_name form a,b where a.id=b.id\x0d\x0a结果如图\x0d\x0a\x0d\x0aEXPLAIN列的解释\x0d\x0atable\x0d\x0a显示这一行的数据是关于哪张表的\x0d\x0atype\x0d\x0a这是重要的列,显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL\x0d\x0apossible_keys\x0d\x0a显示可能应用在这张表中的索引。如果为空,没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句\x0d\x0akey\x0d\x0a实际使用的索引。如果为NULL,则没有使用索引。很少的情况下,MYSQL会选择优化不足的索引。这种情况下,可以在SELECT语句 中使用USE INDEX(indexname)来强制使用一个索引或者用IGNORE INDEX(indexname)来强制MYSQL忽略索引\x0d\x0akey_len\x0d\x0a使用的索引的长度。在不损失精确性的情况下,长度越短越好\x0d\x0aref\x0d\x0a显示索引的哪一列被使用了,如果可能的话,是一个常数\x0d\x0arows\x0d\x0aMYSQL认为必须检查的用来返回请求数据的行数\x0d\x0aExtra\x0d\x0a关于MYSQL如何解析查询的额外信息。将在表4.3中讨论,但这里可以看到的坏的例子是Using temporary和Using filesort,意思MYSQL根本不能使用索引,结果是检索会很慢\x0d\x0a\x0d\x0aextra列返回的描述的意义\x0d\x0aDistinct\x0d\x0a一旦MYSQL找到了与行相联合匹配的行,就不再搜索了\x0d\x0aNot exists\x0d\x0aMYSQL优化了LEFT JOIN,一旦它找到了匹配LEFT JOIN标准的行,就不再搜索了\x0d\x0aRange checked for each Record(index map:#)\x0d\x0a没有找到理想的索引,因此对于从前面表中来的每一个行组合,MYSQL检查使用哪个索引,并用它来从表中返回行。这是使用索引的最慢的连接之一\x0d\x0aUsing filesort\x0d\x0a看到这个的时候,查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行\x0d\x0aUsing index\x0d\x0a列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的,这发生在对表的全部的请求列都是同一个索引的部分的时候\x0d\x0aUsing temporary\x0d\x0a看到这个的时候,查询需要优化了。这里,MYSQL需要创建一个临时表来存储结果,这通常发生在对不同的列集进行ORDER BY上,而不是GROUP BY上\x0d\x0aWhere used\x0d\x0a使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行,并且连接类型ALL或index,这就会发生,或者是查询有问题不同连接类型的解释(按照效率高低的顺序排序)\x0d\x0aconst\x0d\x0a表中的一个记录的最大值能够匹配这个查询(索引可以是主键或惟一索引)。因为只有一行,这个值实际就是常数,因为MYSQL先读这个值然后把它当做常数来对待\x0d\x0aeq_ref\x0d\x0a在连接中,MYSQL在查询时,从前面的表中,对每一个记录的联合都从表中读取一个记录,它在查询使用了索引为主键或惟一键的全部时使用\x0d\x0aref\x0d\x0a这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分(比如,利用最左边前缀)时发生。对于之前的表的每一个行联合,全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少—越少越好\x0d\x0arange\x0d\x0a这个连接类型使用索引返回一个范围中的行,比如使用>或 回答于 2022-11-16


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/8640768.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-19
下一篇 2023-04-19

发表评论

登录后才能评论

评论列表(0条)

保存