MySQL数据分析常用函数方法

执行顺序：

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

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

左连接：以表 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常用字符串函数

用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数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷.

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 缓存集群

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

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

---