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

Category Archives: Database

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 递增的行即可)     […]

龙生   11 Jun 2021
View Details

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

4 月数据库流行度排行榜:三巨头分数暴跌

DB-Engines 4 月份流行度排行已更新(基于 3 月份的整体数据变化)。 从总榜来看,前十数据库的排名和上个月保持一致。虽然排名没有变动,但单个数据库的分数却变化不少。稳居前三的 Oracle、MySQL 和 Microsoft SQL Server 分数出现了较大幅度的下跌,分别减少 46.82、34.14 和 7.33 分。其中 SQL Server 分数已经连续下跌了两个月。若与去年同期的数据相比,三者下跌的分数平均已达到 64 分。 后起之秀 PostgreSQL 和 MongoDB 依旧保持着稳步上升的趋势,分数与上个月相比有小幅度增加,与去年同期相比也平均增加了 40 分左右。 ▲ 前十数据库的分数变化走向 对于排名 20 之后的数据库,以年为维度,排名显著上升的数据库有 Snowflake 和 Clickhouse,Snowflake 由去年同时期的第 100 名上升到现在的第 29 名,后者也从第 71 名上升至第 50 名。两者都属于云数据仓库,Snowflake 的母公司去年上市后更是获得巴菲特青睐,股价飙升。相信这也是它排名上升的主要原因。 最后看看各类型数据库的排名情况。 关系数据库前 10 名 Key-Value 数据库前 10 名 文档数据库前 10 名 时序数据库前 10 名 图数据库前 10 名 DB-Engines 根据流行度对数据库管理系统进行排名,排名每月更新一次。排名的数据依据 5 个不同的指标: Google 以及 Bing 搜索引擎的关键字搜索数量 Google Trends 的搜索数量 Indeed 网站中的职位搜索量 LinkedIn 中提到关键字的个人资料数 Stackoverflow 上相关的问题和关注者数量 这份榜单分析旨在为数据库相关从业人员提供一个技术方向的参考,其中涉及到的排名情况并非基于产品的技术先进程度或市场占有率等因素。无论排名先后,选择适合与企业业务需求相比配的技术才是最重要的。   from:https://www.oschina.net/news/135658/db-engines-ranking-202104

龙生   09 Apr 2021
View Details
1 4 5 6 40