本文首发于 ❄️慕雪的寒舍
字节MySQL连环40问,网图
虽然感觉这玩意和字节跳动没关系,但是管他的?直接开始回答!
会的不全,所以查的GPT
MySQL中有多种类型的锁,主要包括以下几种:
除此之外,还有一个NEXT-KEY锁:
NEXT-KEY 锁是 InnoDB 存储引擎中的一种锁机制,用于解决幻读问题。它是通过将 Gap 锁和 记录锁 组合而成的。
具体来说,当一个事务在 InnoDB 表中执行范围查询时,如使用 <
、<=
、>
、>=
等操作符,InnoDB 引擎会为查询涉及到的范围加上 NEXT-KEY 锁。这个 NEXT-KEY 锁包含两部分:
通过使用 NEXT-KEY 锁,InnoDB 可以有效地避免幻读现象的发生。它保证了在一个事务读取一个范围的数据时,其他事务无法并发地在该范围内插入新的记录,从而保证了读取的一致性。
需要注意的是,NEXT-KEY 锁只在事务隔离级别为可重复读(REPEATABLE READ)或更高级别时使用(MySQL默认隔离级别为可重复读)。在较高的并发环境下,使用 NEXT-KEY 锁可能会增加锁冲突的概率,因此在设计数据库和查询时需要考虑到锁的开销和事务的隔离级别。
这个也是GPT回答的,注意,表格和存储引擎不是同一个概念!
在MySQL中,有以下几种不同的表格类型:
除了以上列举的几种常见的表格类型外,MySQL还支持其他一些特殊用途的表格类型,如Partitioned(分区表格)和Federated(联合表格)等。
在关系型数据库中,表格(Table)是指一个逻辑上的数据结构,用来组织和存储数据。一张表格由若干列(Column)和若干行(Row)组成,每列定义了一种数据类型和一个字段名,表格中的每一行则代表一个实体或记录,每个单元格存储着对应列的一个数值或字符串。
存储引擎(Storage Engine)则是指实现了数据库的表格和索引等功能的底层软件模块,它负责将表格数据存储到磁盘、跟踪并处理事务、执行查询语句等任务。不同的存储引擎具有各自的特点和优缺点,在不同场景下选择合适的存储引擎可以提高数据库的性能和可靠性。
MyISAM
InnoDB
四种隔离级别:读未提交,读已提交,可重复读,串行化;
这部分直接去看我的MySQL索引博客,里面详细介绍了区别,这里就不重写一遍了;
char(8)
里面即便只有一个字符也会占用八个的空间(会用空格进行补齐);顺带说一下varchar和text的区别;需要进行索引的长文可以用TEXT进行存储(注意,只有MyISAM支持全文索引)
如下user1表做测试,会发现我们无法给TEXT类型上普通索引。给出的提示是,BLOG/TEXT
类型不能在没有指定长度的时候上索引;因为你的长度不确定,如果MySQL将一个几万字的TEXT存到内存里面作为索引节点,那么就会占用过多的内存空间。
MariaDB [hello_mysql]> desc user1;
+-------+------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+------------------+------+-----+---------+-------+
| id | int(10) unsigned | NO | PRI | NULL | |
| name | varchar(200) | NO | | NULL | |
| info | text | NO | | NULL | |
+-------+------------------+------+-----+---------+-------+
3 rows in set (0.001 sec)
MariaDB [hello_mysql]> alter table user1 add index(info);
ERROR 1170 (42000): BLOB/TEXT column 'info' used in key specification without a key length
即便在创建列的时候给定了TEXT的长度,依旧不能创建索引。
MariaDB [hello_mysql]> alter table user1 add info1 TEXT(20) NOT NULL;
Query OK, 0 rows affected (0.002 sec)
Records: 0 Duplicates: 0 Warnings: 0
MariaDB [hello_mysql]> desc user1;
+-------+------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+------------------+------+-----+---------+-------+
| id | int(10) unsigned | NO | PRI | NULL | |
| name | varchar(200) | NO | | NULL | |
| info | text | NO | | NULL | |
| info1 | tinytext | NO | | NULL | |
+-------+------------------+------+-----+---------+-------+
4 rows in set (0.001 sec)
MariaDB [hello_mysql]> alter table user1 add index(info1);
ERROR 1170 (42000): BLOB/TEXT column 'info1' used in key specification without a key length
正确的写法如下,需要在创建索引的时候,括号指定索引的长度;比如index(info1(10))
含义就是给info1列的前10个字符建立索引。只要TEXT里面存放的文本前10个字符重复率低,那么这个索引就是有意义的!
MariaDB [hello_mysql]> alter table user1 add index(info1(10));
Query OK, 0 rows affected (0.007 sec)
Records: 0 Duplicates: 0 Warnings: 0
候选键是一些可以选用(备选)为主键或者唯一键的类型;
比如一个学生表里面,包含学生主键的INT自增ID,学生学号,学生身份证,学生姓名,学生性别等等信息;在这个表里面,除了主键这个INT的ID,我们还可以把学生的学号和学生的身份证作为主键或者唯一键,因为他们都包含唯一性!
这时候,这些可以作为主键的列,就叫做候选键;
在《数据库系统概率》这门课里面,会把键称作为码,本质上是一个东西。
到底是谁把key翻译成码的?真无语
一个命令行工具(在bash下使用,不是在MySQL命令行使用)
Myisamchk是MyISAM表维护的一个非常实用的工具。可以使用myisamchk实用程序来获得有关数据库表的信息或检查、修复、优化他们。myisamchk适用MyISAM表(对应.MYI和.MYD文件的表)。
这个命令了解即可,下面是两篇使用博客。有需要再去深入学习用法
http://www.4u4v.net/myisamchk-gadgets-manual.html
https://www.cnblogs.com/analyzer/articles/1381538.html
TIMESTAMP底层一般是4个字节,在MySQL里面进行查询的时候,会根据系统时区,转成可读时间进行输出。包括使用cpp devel包获取到的也是可读时间;
因为只有4个字节,所以TIMESTAMP最多能表示 1970-01-01 00:00:01
到2038-01-19 03:14:07
,这也是一个2038年问题,需要改成8字节存储才能存放更长的时间。
另外,如果你想更加精确的标识时间,而不依赖于MySQL对时间戳的自动转换,那么就可以用BIGINT或者DECIMAL类型来存放时间戳数字,再在应用层进行时间戳和可读时间之间的转换。
两种方式都可以
show index from 表名;
show keys from 表名;
代表通配符,匹配所有字符串。下面举几个例子
查询 '张%'
张丽丽
张扣扣
张三
张阿斯顿
查询 '%张%'
里张里
十大张撒打发
查询 '%张'
xx张
xxxxx张
需要注意,只有关键字%
的使用方式才能用上索引,另外两种匹配方式无法使用索引!
等于 =
不等于 <> !=
大于和大于等于 > >=
小于和小于等于 < <=
区间 BETWEEN .. AND ...
是否在列表中 IN
模糊匹配 LIKE
NULL比较 IS NULL, IS NOT NULL
GPT说的:
总的来说,BLOB适合存储二进制数据,例如图像、音频或视频文件等。而TEXT适合存储纯文本数据,如长文本、文章内容等。根据具体的需求,你可以选择适当的数据类型来存储相应的数据。
实际上,把图片、音频这些静态资源存入数据库是不合理的……
PHP里面的函数,不学,直接跳过
在linux下,MyISAM表格以文件形式存储在数据目录下的对应数据库目录中。每个表格对应一个.MYD数据文件(用于存储表格数据)和一个.MYI索引文件(用于存储表格索引),以及一个.frm表格定义文件(包含表格定义信息,如字段名、数据类型等)
MyISAM使用一种称为“静态行格式”的存储格式来存储表格数据。这种格式用于在磁盘上保存由定长行组成的表格,每个行定长,占用相同的存储空间,以便更快地读取和写入数据。MyISAM表格还支持动态行格式,这种格式允许可变行长度,因此可以更有效地存储可变长度的数据类型(如VARCHAR,TEXT等)。
使用索引,减少查询行数来优化去重操作
查询语句后带上limit就可以
select * from 表名 limit 50;
根据实际使用场景来确定用几列,并没有固定限制。理论上来说需要保持最小原则,不要包含多余的无效列(除非你需要用来进行索引优化,减少回表操作)
now会返回一直到时分秒的信息,current_date只会返回当日日期
GPT
非标准字符串类型是指在数据库中没有明确定义或标准化的字符串数据类型。这些类型通常是特定数据库管理系统(DBMS)或应用程序开发框架所支持的扩展。由于不同的DBMS和框架有各自的特性和需求,可能会引入额外的非标准字符串类型以满足特定的数据存储和操作需求。
举例来说,MySQL数据库在其标准字符串类型中包含了CHAR、VARCHAR、TEXT等。而非标准字符串类型可能是根据具体需求和扩展开发的,如JSON、XML、BLOB、CLOB等。这些非标准类型在一些特定场景中使用广泛,例如存储非结构化的文本数据、大型二进制数据、以及存储和查询复杂的结构化数据等。
需要注意的是,非标准字符串类型在不同的DBMS和开发框架之间可能存在差异,并且在跨平台和迁移时可能会出现兼容性问题。因此,在使用非标准字符串类型时,建议仔细了解相关的文档和规范,并评估其对应用程序的影响和可移植性。
以下列举了一些常见的通用SQL函数:
这只是一小部分通用SQL函数的例子,实际上还有很多其他的函数可用于不同的数据处理和查询需求。需要注意的是,尽管这些函数在大多数DBMS中都存在,但某些特定的DBMS可能会提供额外的函数或有稍微不同的语法,因此在使用函数时应查阅相应的文档和规范以确保兼容性和正确性。
肯定支持,这个问题第四点就已经详细问了
因为浮点数的精度问题,可以用BIGINT来存放以分为单位的货币,实际调用的时候再加上小数点,来保证数据准确。
如果不用BIGINT,那就需要用DECIMAL来存放货币。
B站冲浪看到的
在MySQL中,有几个与权限相关的系统表和视图,用于管理用户、角色和权限。以下是一些常见的权限相关的表和视图:
除了上述的表之外,MySQL还提供了一些权限相关的视图,这些视图可以方便地查看用户、角色和权限的信息,如:
如下是个使用示例
select * from information_schema.USER_PRIVILEGES;
这些表和视图可以通过查询相应的系统表或视图来查看和管理用户、角色和权限。请注意,具体的系统表和视图名称可能因MySQL版本和配置而有所不同。为了确保准确性,请参考MySQL官方文档或特定版本的文档。
TEXT CHAR VARCHAR,详见第五点
没见过这种业务,只能问GPT
对于一个MySQL作为发布系统存储的场景,处理每天超过五万条增量数据并且需要保持三年的数据,以下是一些优化建议:
以上是一些常见的优化建议,具体优化方案还需要根据实际场景和需求进行调整。同时,建议在进行优化前,充分了解应用的读写特征、数据访问模式和业务需求,以便有针对性地进行优化工作。
底层用B+实现,优化索引方式见索引博客 https://blog.musnow.top/posts/3474107655/
索引失效,见索引博客 https://blog.musnow.top/posts/3474107655/
太宽泛了,不好回答
和29题重合,不做回答
见索引博客 https://blog.musnow.top/posts/3474107655/
见事务博客 https://blog.musnow.top/posts/2200233148/
SQL注入漏洞是一种常见的安全漏洞,它可以使攻击者通过构造恶意的SQL语句来绕过应用程序的输入验证,进而执行非法的数据库操作或获取敏感信息。以下是SQL注入漏洞产生的原因和一些防止方法:
总之,为了防止SQL注入漏洞,关键是要对用户输入数据进行合理验证、过滤和转义处理,并使用参数化查询或预编译语句来构造SQL语句。同时,保持应用程序和数据库的安全性,并及时更新和修补已知的安全漏洞。
肯定是根据具体情况回答
感觉这道题有问题,不管他
和31重合,不回答
总结:
见事务博客 https://blog.musnow.top/posts/2200233148/
包括DQL数据查询语言,DML数据操作语言(增删改),数据控制语言DCL用来管理数据库,事务控制语言TCL用来控制事务,数据定义语言DDL用来创建删除表
原子性、隔离性、持久性;这里说的完整性应该就是一致性;
具体的解释依旧是去看事务的博客 https://blog.musnow.top/posts/2200233148/