Category Archives: MySQL

mysql字符串拆分实现split功能

【0】需求   【0.1】需求描述 数据库中 num字段值为： 实现的效果：需要将一行数据变成多行   【0.2】实现的SQL

  涉及的知识点 【1】字符串拆分： SUBSTRING_INDEX（str, delim, count） 参数解说     解释 str 　　　　需要拆分的字符串 delim 　　  分隔符，通过某字符进行拆分 count 　　  当 count 为正数，取第 n 个分隔符之前的所有字符； 当 count 为负数，取倒数第 n 个分隔符之后的所有字符。 举例

所以，我们的核心代码中的 -1 ，就是获取以逗号为分隔符的最后一个值；也就是7788 【2】替换函数：replace( str, from_str, to_str) 参数名　　   解释 str 　　　　  需要进行替换的字符串 from_str 　　需要被替换的字符串 to_str 　　　 需要替换的字符串 2. 举例

  【3】获取字符串长度：LENGTH( str ) 参数名 　　解释 str 　　　　需要计算长度的字符串 举例

【4】实现的原理解析   【4.0】实现SQL 需要解析的SQL

此处利用 mysql 库的 help_topic 表的 help_topic_id 来作为变量，因为 help_topic_id 是自增的，当然也可以用其他表的自增字段辅助。 help_topic 表： 注意，这个辅助表的ID最大长度只有642；如果过长的字符串，可能需要借助其他自增的辅助表（可以是现有表，也可以自己造一个 1,2,3,4 递增的行即可）     […]

max_allowed_packet设置问题

最近在运行的项目出现了一个线上事故，有人反映商城的东西下不了单了，到后台看了一下，果然报了一个错 Cause: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (1046 > 1024). You can change this value on the server by setting the max_allowed_packet' variable.; ]; Packet for query is too large (1046 > 1024). You can change this value on the server by setting the max_allowed_packet' variable.; nested exception is com.mysql.jdbc.PacketTooBigException: Packet for query is too large (1046 > 1024). You can change this value on the server by setting the max_allowed_packet' variable. 其实上面的报错信息就给出了解决方案了，原来mysql根据配置文件会限制server接受的数据包大小。如果一次插入数据库中的数据太大的话就会失败，官方也有这方面的介绍 官方介绍 用命令行查看show VARIABLES like '%max_allowed_packet%';果然max_allowed_packet太小了 解决方法 1、修改配置文件（推荐） 在mysql中的my.ini文件中（在programdata隐藏文件中），修改max_allowed_packet的值 比如：max_allowed_packet=128M 然后重启mysql就可以 2、命令行中设置 set global max_allowed_packet = […]

MySQL show processlist说明

show processlist和show full processlist processlist命令的输出结果显示了有哪些线程在运行，不仅可以查看当前所有的连接数，还可以查看当前的连接状态帮助识别出有问题的查询语句等。 如果是root帐号，能看到所有用户的当前连接。如果是其他普通帐号，则只能看到自己占用的连接。showprocesslist只能列出当前100条。如果想全部列出，可以使用SHOW FULL PROCESSLIST命令

  各个列的含义： ①.id列，用户登录mysql时，系统分配的"connection_id"，可以使用函数connection_id()查看 ②.user列，显示当前用户。如果不是root，这个命令就只显示用户权限范围的sql语句 ③.host列，显示这个语句是从哪个ip的哪个端口上发的，可以用来跟踪出现问题语句的用户 ④.db列，显示这个进程目前连接的是哪个数据库 ⑤.command列，显示当前连接的执行的命令，一般取值为休眠（sleep），查询（query），连接（connect）等 ⑥.time列，显示这个状态持续的时间，单位是秒 ⑦.state列，显示使用当前连接的sql语句的状态，很重要的列。state描述的是语句执行中的某一个状态。一个sql语句，以查询为例，可能需要经过copying to tmp table、sorting result、sending data等状态才可以完成 ⑧.info列，显示这个sql语句，是判断问题语句的一个重要依据 在主从复制环境中，show processlist或show full processlist对于判断状态很有帮助，例如下面的state列： from:https://www.cnblogs.com/flzs/p/11044689.html

mysql select into的用法

MySQL不支持Select Into语句直接备份表结构和数据,一些种方法可以代替,如下:

  from:https://blog.csdn.net/zwldx/article/details/82227533

MySql时间戳函数

参考链接：https://www.cnblogs.com/jhy-ocean/p/5560857.html   MySql时间戳涉及的函数 date_format(date, format) 函数，MySQL日期格式化函数date_format() unix_timestamp() 函数 str_to_date(str, format) 函数 from_unixtime(unix_timestamp, format) 函数，MySQL时间戳格式化函数from_unixtime 时间转字符串

时间转时间戳

字符串转时间

字符串转时间戳

时间戳转时间

时间戳转字符串

附表 MySQL日期格式化（format）取值范围。   值 含义 秒 %S、%s 两位数字形式的秒（ 00,01, …, 59） 分 %I、%i 两位数字形式的分（ 00,01, …, 59） 小时 %H 24小时制，两位数形式小时（00,01, …,23） %h 12小时制，两位数形式小时（00,01, …,12） %k 24小时制，数形式小时（0,1, …,23） %l 12小时制，数形式小时（0,1, …,12） %T 24小时制，时间形式（HH:mm:ss） %r  12小时制，时间形式（hh:mm:ss AM 或 PM） %p AM上午或PM下午   周  %W 一周中每一天的名称（Sunday,Monday, …,Saturday）  %a 一周中每一天名称的缩写（Sun,Mon, …,Sat） %w 以数字形式标识周（0=Sunday,1=Monday, …,6=Saturday） %U 数字表示周数，星期天为周中第一天 %u 数字表示周数，星期一为周中第一天 天 %d 两位数字表示月中天数（01,02, …,31） %e  数字表示月中天数（1,2, …,31）  %D 英文后缀表示月中天数（1st,2nd,3rd […]

MySQL 函数

MySQL 有很多内置的函数，以下列出了这些函数的说明。 MySQL 字符串函数 函数 实例 ASCII(s)  返回字符串 s 的第一个字符的 ASCII 码。 返回 CustomerName 字段第一个字母的 ASCII 码：

CHAR_LENGTH(s)  返回字符串 s 的字符数 返回字符串 RUNOOB 的字符数

CHARACTER_LENGTH(s) 返回字符串 s 的字符数 返回字符串 RUNOOB 的字符数

CONCAT(s1,s2…sn)  字符串 s1,s2 等多个字符串合并为一个字符串 合并多个字符串

CONCAT_WS(x, s1,s2…sn) 同 CONCAT(s1,s2,…) 函数，但是每个字符串之间要加上 x，x 可以是分隔符 合并多个字符串，并添加分隔符：

FIELD(s,s1,s2…)  返回第一个字符串 s 在字符串列表(s1,s2…)中的位置 返回字符串 c 在列表值中的位置：

FIND_IN_SET(s1,s2)  返回在字符串s2中与s1匹配的字符串的位置 返回字符串 c 在指定字符串中的位置：

FORMAT(x,n)  函数可以将数字 x 进行格式化 "#,###.##", 将 x 保留到小数点后 n 位，最后一位四舍五入。 格式化数字 "#,###.##" 形式：

INSERT(s1,x,len,s2)  字符串 s2 替换 s1 的 x 位置开始长度为 len 的字符串 从字符串第一个位置开始的 […]

MySQL 中 datetime 和 timestamp 的区别与选择

MySQL 中常用的两种时间储存类型分别是datetime和 timestamp。如何在它们之间选择是建表时必要的考虑。下面就谈谈他们的区别和怎么选择。 1 区别 1.1 占用空间 类型 占据字节 表示形式 datetime 8 字节 yyyy-mm-dd hh:mm:ss timestamp 4 字节 yyyy-mm-dd hh:mm:ss 1.2 表示范围 类型 表示范围 datetime '1000-01-01 00:00:00.000000' to '9999-12-31 23:59:59.999999' timestamp '1970-01-01 00:00:01.000000' to '2038-01-19 03:14:07.999999' timestamp翻译为汉语即"时间戳"，它是当前时间到 Unix元年(1970 年 1 月 1 日 0 时 0 分 0 秒)的秒数。对于某些时间的计算，如果是以 datetime 的形式会比较困难，假如我是 1994-1-20 06:06:06 出生，现在的时间是 2016-10-1 20:04:50 ，那么要计算我活了多少秒钟用 datetime 还需要函数进行转换，但是 timestamp 直接相减就行。 1.3 时区 timestamp 只占 4 个字节，而且是以utc的格式储存， 它会自动检索当前时区并进行转换。 datetime以 8 个字节储存，不会进行时区的检索. 也就是说，对于timestamp来说，如果储存时的时区和检索时的时区不一样，那么拿出来的数据也不一样。对于datetime来说，存什么拿到的就是什么。 还有一个区别就是如果存进去的是NULL，timestamp会自动储存当前时间，而 datetime会储存 NULL。 2 测试 我们新建一个表 插入数据 查看数据，可以看到存进去的是NULL，timestamp会自动储存当前时间，而 datetime会储存NULL 把时区修改为东 9 区，再查看数据，会会发现 timestamp 比 datetime 多一小时 如果插入的是无效的呢？假如插入的是时间戳 结果是0000-00-00 00:00:00，根据官方的解释是插入的是无效的话会转为 0000-00-00 00:00:00，而时间戳并不是MySQL有效的时间格式。 那么什么形式的可以插入呢，下面列举三种

  3 选择 如果在时间上要超过Linux时间的，或者服务器时区不一样的就建议选择 datetime。 如果是想要使用自动插入时间或者自动更新时间功能的，可以使用timestamp。 如果只是想表示年、日期、时间的还可以使用 year、 date、 time，它们分别占据 1、3、3 字节，而datetime就是它们的集合。   from:https://segmentfault.com/a/1190000017393602

MySQL触发器更新本表数据异常:Can’t update table 'tbl' in stored function/trigger because it is already used by statement which invoked this

如果你在触发器里面对刚刚插入的数据进行了 insert/update, 则出现这个问题。因为会造成循环的调用.   create trigger test before update on test for each row update test set NEW.updateTime = NOW() where id=NEW.ID; END 应该使用set操作，而不是在触发器里使用 update,比如 create trigger test before update on test for each row set NEW.updateTime = NOW(); END ———————————————— 版权声明：本文为CSDN博主「老紫竹」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/java2000_net/article/details/3857579

MySQL中的JSON类型

前言（废话） 昨天抽了点时间在网上搜列了一个开源项目，项目挺完整的，前后台分离还带有微信小程序，我Clone下代码，经过一番倒腾，嘿~还真就跑起来了。在这个过程中，体验了一把VUE项目工程细节，因为之前没有接触过这一块，所以还是花费了点时间，好在开源项目的QQ群里楼主帮忙看了一下，才得以顺利往后进行。后来也有很多网友向楼主提问，也抛出了一些问题，其中有个问题到引起了我的注意。 有个小伙伴执行SQL的时候报错了，以为项目中给的SQL脚本不全，但是在群里他并没有给出报错细节的截图，楼主后来也就提示了他一句MySQL版本需要在5.7以上，但是后面就没有更多消息了。 今天早上我还在上班路上，群里的小伙伴就私信我，说能否帮他看下数据库的问题。等我到了公司再回复他的时候，他告诉我说数据库问题已经解决了，我追问了一下细节，原来是开源项目中的数据库建表语句中包含JSON类型字段，导致了他批量执行SQL脚本不成功。其实这样的问题，在执行脚本的时候遇到错误是有日志的，详细看下日志应该明了。 我其实是没有注意到这个细节的，因为我前天安装的数据库就直接上了8.0，屏蔽了这个问题，但是，MySQL数据库现在支持JSON类型，挺新奇的，因为之前没有用过，并不熟悉，所以这一次，让我逮到个了解它的机会。 关于MySQL的JSON类型 JSON估计大家伙都熟悉了，我就不再介绍这方面内容。其实在MySQL数据库中，也直到5.7这个版本，才开始引入JSON数据类型，在此之前如果想在表中保存JSON格式类型的数据，则需要依靠varchar或者text之类的数据类型，如果在低于5.7版本的数据库中使用了JSON类型来建表，显然是不会成功的。 （截图为MySQL官网文档） 如何使用JSON类型 建表 在MySQL中创建具有JSON数据列的表，其实和数据类型没有太大区别，具体举例如下：

新增数据 插入一条语句，注意看JSON数据列的内容：

这里需要提醒的是： JSON列存储的数据要么是NULL，要么必须是JSON格式数据，否则会报错。 JSON数据类型是没有默认值的（声明时"DEFAULT NULL"）。 JSON数据类型意义 其实，没有JSON数据类型的支持，我们一样可以通过varchar类型或者text等类型来保存这一格式的数据，但是，为什么还要专门增加这一数据格式的支持呢？其中肯定有较varchar或者text来存储此类型更优越的地方。 保证了JSON数据类型的强校验，JSON数据列会自动校验存入此列的内容是否符合JSON格式，非正常格式则报错，而varchar类型和text等类型本身是不存在这种机制的。 MySQL同时提供了一组操作JSON类型数据的内置函数。 更优化的存储格式，存储在JSON列中的JSON数据会被转成内部特定的存储格式，允许快速读取。 可以基于JSON格式的特征支持修改特定的键值。（即不需要把整条内容拿出来放到程序中遍历然后寻找替换再塞回去，MySQL内置的函数允许你通过一条SQL语句就能搞定） MySQL关于JSON的内置函数 MySQL关于JSON数据格式的操作提供了很多高效率的内置函数，我们可以从MySQL官网上找到很详细的介绍和使用说明，下面贴一张JSON函数的指南： （截图为MySQL官方文档） 其实我们从JSON功能介绍的主页也可以看到，这些内置函数支持我们创建、查找、替换和返回值等相关的操作，像我们替换指定内容的操作就可以使用JSON_REPLACE()这个函数，不过最后实现通过纯SQL语句执行最终的内容替换，你还需要通过执行UPDATE语句，比如：

其中“$.***”表示找到JSON内容中匹配的修改字段。 更多关于这些内置函数的用法，大家都可以到官网（链接请查看本文参考资料）的文档上去查阅，写的十分详细而且还有举例。 参考资料： 1、https://zhuanlan.zhihu.com/p/31823258 2、https://dev.mysql.com/doc/refman/5.7/en/json-functions.html   from:https://www.cnblogs.com/captainad/p/11176127.html

MySQL 查询优化

索引 索引是什么 MySQL 官方对索引的定义为：索引（Index）是帮助 MySQL 高效获取数据的数据结构。可以得到索引的本质：索引是数据结构。 可以简单理解为排好序的快速查找数据结构。 在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。 一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。 优缺点 优点 提高数据检索的效率，降低数据库的 IO 成本。 通过索引列对数据进行排序，降低数据排序的成本，降低了 CPU 的消耗。 缺点 虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行 INSERT、UPDATE 和 DELETE。因为更新表时，MySQL 不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为 更新所带来的键值变化后的索引信息。 实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以索引列也是要占用空间 的。 B-Tree 和 B+Tree 区别 B-Tree 的关键字和记录是放在一起的，叶子节点可以看作外部节点，不包含任何信息；B+Tree 的非叶子节点中只有关键字和指向下一个节点的索引，记录只放在叶子节点中。 在 B-Tree 中，越靠近根节点的记录查找时间越快，只要找到关键字即可确定记录的存在；而 B+Tree 中每个记录的查找时间基本是一样的，都需要从根节点走到叶子节点，而且在叶子节点中还要再比较关键字。从这个角度看 B-Tree 的性能好像要比 B+Tree 好，而在实际应用中却是 B+Tree 的性能要好些。因为 B+Tree 的非叶子节点不存放实际的数据，这样每个节点可容纳的元素个数比 B-Tree 多，树高比 B-Tree 小，这样带来的好处是减少磁盘访问次数。尽管 B+Tree 找到一个记录所需的比较次数要比 B-Tree 多，但是一次磁盘访问的时间相当于成百上千次内存比较的时间，因此实际中 B+Tree 的性能可能还会好些，而且 B+Tree 的叶子节点使用指针连接在一起，方便顺序遍历（例如查看一个目录下的所有文件，一个表中的所有记录等），这也是很多数据库和文件系统使用 B+Tree 的缘故。 为什么 B+Tree 比 B-Tree 更适合实际应用中操作系统的文件索引和数据库索引？ B+Tree 的磁盘读写代价更低 B+Tree 的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对 B-Tree 更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说 IO 读写次数也就降低了。 B+Tree 的查询效率更加稳定 由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。 索引分类 单值索引：即一个索引只包含单个列，一个表可以有多个单列索引 建表时，加上 key(列名) 指定 单独创建，create index 索引名 on 表名(列名) 单独创建，alter table […]