一切福田,不離方寸,從心而覓,感無不通。

Category Archives: MySQL

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 = […]

龙生   09 Jun 2021
View Details

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

龙生   08 Jun 2021
View Details

mysql select into的用法

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

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

龙生   08 Jun 2021
View Details

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 […]

龙生   04 Jun 2021
View Details

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 的字符串 从字符串第一个位置开始的 […]

龙生   19 May 2021
View Details

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

龙生   14 May 2021
View Details

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

龙生   11 May 2021
View Details

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

龙生   09 Apr 2021
View Details

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 […]

龙生   25 Jan 2021
View Details
1 3 4 5 24