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

Category Archives: Database

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

如何备份PostgreSQL数据库 常见的几个备份命令使用

一般我们建站使用较多的还是固定开源CMS程序,且基本上也使用的是PHP+MYSQL程序,所以数据库上较多的还是使用的MYSQL数据库。但是前几天老左有遇到一个网友他使用的是PostgreSQL数据库,实际上这个数据库我们在使用虚拟主机的时候也是有见过的,但是确实用的不多。 如果我们需要备份PostgreSQL数据库的话,一般如果我们服务器WEB环境自带的管理小工具是可以直接导出备份的,但是如果是运维工程师自己编译的WEB系统,那我们就需要用到其他的单独命令备份,这里我们记录下如何通过PostgreSQL命令备份数据库。 第一、一键快速备份单数据库 su – postgres 这里我们登陆数据库。 pg_dump laozuo.org > laozuo.org.bak 通过命令一键将我们的数据库名换成我们需要备份的,然后备份。这里我们可以将备份的数据下载到本地。 psql laozuo < dbname.bak 如果我们需要恢复数据库可以用psql命令来恢复,是不是有点像我们MYSQL恢复数据一样。 第二、远程备份数据库 一般远程备份数据库我们个人使用的不多的,我们还是老老实实在当前服务器操作比较多见,但是这里的方法老左也记录一下。 pg_dump -h 1.1.1.1 -p 1234 dbname > dbname.bak 根据命令及端口进行备份,注意数据库名修改成我们自己的。 第三、设置定时自动备份 这个我们很多朋友都有用的,一般项目文件动的不多,一般都是数据库在增减。所以我们定期备份数据库即可,但是我们需要做到的是定时备份。 1、登录数据库 su – postgres 和上面一样,我们要登录数据库,然后设置定时任务。 2、创建备份目录 mkdir -p ~/dbbackups 我们需要创建一个备份目录。 3、创建定时任务 crontab -e 然后需要编辑文件。 0 0 * * 0 pg_dump -U postgres laozuo> ~/dbbackups/laozuo.org.bak 编辑完毕保存后,我们运营一次看看,是否备份进入文件夹。 这里我们在备份完毕PostgreSQL数据库之后,我们还是需要定期下载或者SCP推送到其他服务器。之前有个朋友确实会定时备份,但是他备份到的还是自己当前服务器。于是前几天发现服务器故障数据丢失,他悲剧了。所以我们还是需要备份到本地。   from:https://www.laozuo.org/16772.html

龙生   19 Mar 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

5分钟学会MySQL-this is incompatible with sql_mode=only_full_group_by错误解决方案

 5分钟学会MySQL-  "this is incompatible with sql_mode=only_full_group_by"错误解决方案   前言: 一、原理层面 这个错误发生在mysql 5.7 版本及以上版本会出现的问题: mysql 5.7版本默认的sql配置是:sql_mode="ONLY_FULL_GROUP_BY",这个配置严格执行了"SQL92标准"。 很多从5.6升级到5.7时,为了语法兼容,大部分都会选择调整sql_mode,使其保持跟5.6一致,为了尽量兼容程序。   二、sql层面 在sql执行时,出现该原因: 简单来说就是:输出的结果是叫target list,就是select后面跟着的字段,还有一个地方group by column,就是 group by后面跟着的字段。由于开启了ONLY_FULL_GROUP_BY的设置,所以如果一个字段没有在target list 和group by字段中同时出现,或者是聚合函数的值的话,那么这条sql查询是被mysql认为非法的,会报错误。       一、查看sql_mode的语句如下  

      二、解决方案-(推荐解决方案二)   ①解决方案一:sql语句暂时性修改sql_mode

  问题: 重启mysql数据库服务之后,ONLY_FULL_GROUP_BY还会出现。 ②解决方案二:完美解决方案。 需修改mysql配置文件,通过手动添加sql_mode的方式强制指定不需要ONLY_FULL_GROUP_BY属性, my.cnf位于etc文件夹下,vim下光标移到最后,添加如下:

重启mysql服务,顺利解决。   from:https://blog.csdn.net/qq_42175986/article/details/82384160

龙生   15 Jan 2021
View Details

MySQL的JOIN(一):用法

JOIN的含义就如英文单词“join”一样,连接两张表,大致分为内连接,外连接,右连接,左连接,自然连接。这里描述先甩出一张用烂了的图,然后插入测试数据。  

笛卡尔积:CROSS JOIN 要理解各种JOIN首先要理解笛卡尔积。笛卡尔积就是将A表的每一条记录与B表的每一条记录强行拼在一起。所以,如果A表有n条记录,B表有m条记录,笛卡尔积产生的结果就会产生n*m条记录。下面的例子,t_blog有10条记录,t_type有5条记录,所有他们俩的笛卡尔积有50条记录。有五种产生笛卡尔积的方式如下。

内连接:INNER JOIN 内连接INNER JOIN是最常用的连接操作。从数学的角度讲就是求两个表的交集,从笛卡尔积的角度讲就是从笛卡尔积中挑出ON子句条件成立的记录。有INNER JOIN,WHERE(等值连接),STRAIGHT_JOIN,JOIN(省略INNER)四种写法。至于哪种好我会在MySQL的JOIN(二):优化讲述。示例如下。

  左连接:LEFT JOIN 左连接LEFT JOIN的含义就是求两个表的交集外加左表剩下的数据。依旧从笛卡尔积的角度讲,就是先从笛卡尔积中挑出ON子句条件成立的记录,然后加上左表中剩余的记录(见最后三条)。

  右连接:RIGHT JOIN 同理右连接RIGHT JOIN就是求两个表的交集外加右表剩下的数据。再次从笛卡尔积的角度描述,右连接就是从笛卡尔积中挑出ON子句条件成立的记录,然后加上右表中剩余的记录(见最后一条)。

外连接:OUTER JOIN 外连接就是求两个集合的并集。从笛卡尔积的角度讲就是从笛卡尔积中挑出ON子句条件成立的记录,然后加上左表中剩余的记录,最后加上右表中剩余的记录。另外MySQL不支持OUTER JOIN,但是我们可以对左连接和右连接的结果做UNION操作来实现。

USING子句 MySQL中连接SQL语句中,ON子句的语法格式为:table1.column_name = table2.column_name。当模式设计对联接表的列采用了相同的命名样式时,就可以使用 USING 语法来简化 ON 语法,格式为:USING(column_name)。 所以,USING的功能相当于ON,区别在于USING指定一个属性名用于连接两个表,而ON指定一个条件。另外,SELECT *时,USING会去除USING指定的列,而ON不会。实例如下。

自然连接:NATURE JOIN 自然连接就是USING子句的简化版,它找出两个表中相同的列作为连接条件进行连接。有左自然连接,右自然连接和普通自然连接之分。在t_blog和t_type示例中,两个表相同的列是id,所以会拿id作为连接条件。 另外千万分清下面三条语句的区别 。 自然连接:SELECT * FROM t_blog NATURAL JOIN t_type; 笛卡尔积:SELECT * FROM t_blog NATURA JOIN t_type; 笛卡尔积:SELECT * FROM t_blog NATURE JOIN t_type;

补充 博客开头给出的第一张图除去讲了的内连接、左连接、右连接、外连接,还有一些特殊的韦恩图,这里补充一下。

写完这篇博客发现有点“孔乙己:茴字的四种写法的感觉”,但还是有收获的。另外,等三面通知等的好急啊!! 引用 http://www.cnblogs.com/fudashi/p/6572101.html http://blog.csdn.net/wjc19911118/article/details/9716391 http://blog.csdn.net/taylor_tao/article/details/7068511 from:https://www.cnblogs.com/fudashi/p/7491039.html

龙生   07 Jan 2021
View Details
1 4 5 6 44