MySQL之四大引擎、账号管理以及建库
目录
一.数据库存储引擎
查看存储引擎命令:SHOW ENGINES
DEFAULT: 为默认的引擎
YES: 表示可以使用
NO: 表示不能使用
①?MEMORY
MEMORY
是 MySQL 数据库中的一种存储引擎,它将表的数据存储在内存中而不是磁盘上。也称为 HEAP 存储引擎,因为在创建表时可以使用 语句来指定。ENGINE=MEMORY
以下是一些 存储引擎的特点和限制:
MEMORY
特点:
- 快速访问:?数据存储在内存中,因此读取和写入速度较快。
- 表锁:?存储引擎使用表级锁,而不是行级锁,这可能会影响并发性能。
MEMORY
- 易于配置:?不需要复杂的配置,可以很容易地在内存中创建表。
限制:
- 数据丢失:?因为数据存储在内存中,数据库重启或服务器关闭会导致数据丢失。
- 表大小限制:?存储引擎对表的大小有限制,因为它受系统的可用内存和配置参数的限制。
MEMORY
- 不支持事务:?不支持事务处理,这意味着不能使用?或?操作。
COMMIT
ROLLBACK
请注意,尽管 存储引擎对于某些特定的使用场景非常有用,但由于其限制,它并不适用于所有情况。在选择存储引擎时,需要考虑到应用程序的需求、数据量、并发性能等因素。
MEMORY
?②MyISAM
MyISAM 是 MySQL 数据库中一种常见的存储引擎,它在很长一段时间内是 MySQL 默认的存储引擎,但从 MySQL 5.5 版本开始,InnoDB 取代了 MyISAM 成为默认存储引擎。尽管如此,MyISAM 仍然在某些场景中有其用武之地。
以下是 MyISAM 存储引擎的一些特点和注意事项:
特点:
表级锁:MyISAM 使用表级锁,而不是行级锁。这可能导致在高并发写入的情况下性能下降。
支持全文索引:MyISAM 存储引擎支持全文本搜索,这使得它在特定的搜索应用中很有用。
不支持事务:MyISAM 不支持事务处理,这意味着不能使用 或 操作。
COMMIT
ROLLBACK
表压缩:MyISAM 支持表级别的压缩,可以减小存储空间。
缓存:MyISAM 使用系统文件缓存来缓存索引和数据。
易于备份: 由于表级锁的使用,MyISAM 在备份时相对容易处理。
注意事项:
不支持事务: 如果你的应用程序需要事务支持,应该考虑使用 InnoDB 等支持事务的存储引擎。
不适合高并发写入: 由于表级锁的使用,MyISAM 在高并发写入的情况下性能可能不如 InnoDB。
请注意,虽然 MyISAM 有其用途,但在现代应用中,特别是需要事务支持或高并发性能的应用中,InnoDB 存储引擎更为常见。选择存储引擎应该根据应用程序的具体需求来做出。
?③InnoDB
InnoDB 是 MySQL 数据库中的一种常用存储引擎,它在现代 MySQL 版本中被广泛使用,并且是默认的存储引擎(从 MySQL 5.5 版本开始)。InnoDB 提供了许多优点,特别适合需要事务支持和高并发性能的应用。
以下是 InnoDB 存储引擎的关键特点和优势:
事务支持:InnoDB 是一个支持事务处理的存储引擎。它遵循 ACID(原子性、一致性、隔离性、持久性)属性,允许使用 和 来管理事务。
COMMIT
ROLLBACK
行级锁定:InnoDB 支持行级锁定,而不是表级锁定。这意味着它可以在同一表中的不同行之间进行并发操作,提高了多用户环境下的性能。
外键约束:InnoDB 支持外键,可以保持数据完整性,实现表之间的关联关系。
崩溃恢复:InnoDB 提供了崩溃恢复的能力,它有日志文件(redo log)来记录数据修改操作,使得数据库在异常情况下可以进行恢复。
并发控制:InnoDB 使用 MVCC(多版本并发控制)来处理并发访问,允许读取操作不被写入操作所阻塞。
自动增加的大小: InnoDB 表的大小可以根据需要自动增加,而不需要手动设置或分配空间。
性能优化: InnoDB 针对高并发负载进行了优化,适合于需要处理大量并发读写请求的应用。
虽然 InnoDB 在许多方面提供了优越性能和功能,但在某些特定场景下,例如对于只读或很少更新的数据,或者需要全文索引支持的情况下,可能会选择其他存储引擎。选择存储引擎应该根据应用程序的需求和性能特点来决定。
?④ARCHIVE
ARCHIVE
是 MySQL 数据库中的一种特殊存储引擎。与 InnoDB 或 MyISAM 不同, 存储引擎的设计目标主要是为了实现高压缩率和快速插入,适用于对数据进行归档和存储的场景。ARCHIVE
以下是 存储引擎的一些特点和适用场景:
ARCHIVE
高压缩率: 存储引擎使用 zlib 压缩算法,因此对于大量相似数据的存储非常高效。这使得它在归档大量历史数据时能够显著减小存储空间。
ARCHIVE
只支持 INSERT 和 SELECT 操作: 存储引擎主要用于插入和检索大量数据。它不支持 UPDATE、DELETE 或其他复杂的操作,因此适用于一次性插入大量数据并且之后只进行查询的场景。
ARCHIVE
不支持索引: 存储引擎不支持普通的 B 树索引,这意味着查询速度较慢。它主要适用于需要大量历史数据的存档场景,而不是需要频繁检索的情况。
ARCHIVE
适用于日志和归档数据: 由于其高压缩率和只读特性, 存储引擎适用于存储日志数据或归档历史数据。
ARCHIVE
需要注意的是,由于 存储引擎的特性,它并不适用于所有类型的应用。在选择存储引擎时,应该考虑到应用程序的读写模式、数据量、查询需求等因素。对于频繁读取和更新的数据表,通常会选择其他存储引擎,如 InnoDB。
ARCHIVE
二.数据库管理
?元数据库(Metadatabase)通常是指一个数据库中存储关于该数据库中其他数据库和它们之间关系的信息的数据库。这种数据库通常用于管理和存储关于其他数据库对象(如表、列、索引等)的元数据。元数据库的存在使得用户和应用程序能够查询和了解数据库中存储的数据结构和关系,从而更有效地管理和操作数据库。记录MySQL自身数据的数据库
2.1.三大数据库?
2.1.1.information_schema
- 用途:?是一个包含元数据(metadata)信息的数据库,提供了关于数据库结构和对象的信息,允许用户查询和了解数据库的结构、表、列、索引等元数据信息。
information_schema
- 内容:?包含一系列的表,例如?(数据库)、(表)、(列)、(统计信息)、(键列使用情况)等,这些表存储了数据库和其对象的元数据信息。
SCHEMATA
TABLES
COLUMNS
STATISTICS
KEY_COLUMN_USAGE
- 用途示例:?用户可以通过查询?来获取数据库中的表、列、索引、约束等信息,用于数据库管理、查询优化和设计。
information_schema
2.1.2.mysql
- 用途:?是存储 MySQL 服务器的配置和授权信息的数据库,包含了用户账户、权限、全局变量等 MySQL 服务器配置和安全相关的信息。
mysql
- 内容:?包含了用户、密码、授权信息、全局变量等表,如?、、、?等,用于存储访问权限和服务器配置。
user
db
tables_priv
columns_priv
- 用途示例:?管理员可以通过对?数据库进行操作,管理用户权限、修改全局变量设置,以及控制数据库的安全和行为。
mysql
2.1.3.performance_schema
- 用途:?是用于性能监控和诊断的数据库,提供了关于数据库服务器性能和活动的详细信息,允许用户查询和分析数据库的性能特征。
performance_schema
- 内容:?包含了用于监控数据库性能的一系列表,如?、、?等,这些表提供了关于语句执行、锁、文件 I/O 等性能相关的信息。
events_statements_summary_by_digest
mutex_instances
file_summary_by_event_name
- 用途示例:?数据库管理员和开发人员可以通过查询?中的表来了解数据库服务器的性能状况,识别潜在的性能问题,并进行性能调优和优化。
performance_schema
?用于访问数据库的元数据信息, 用于管理 MySQL 服务器的配置和安全, 则用于监控和诊断数据库服务器的性能。这三个数据库在不同层面上提供了对 MySQL 数据库系统的重要信息和控制。
information_schema? mysql?
performance_schema
2.2.相关操作
使用数据库:
use 数据库名
创建数据库:
create data base if not exists 数据库名 default charset utf8 collate utf8_general_ci;(完整的)
查询数据库:
show databases;
删除数据库:
drop database数据库名;
2.3.权限相关的表
mysql.user
表:(用户层权限)
- 存储数据库用户的基本信息,包括用户名、主机、密码等。
- 用于管理用户的认证信息。
mysql.db
表:(数据库层权限)
- 记录数据库级别的权限信息,包括哪个用户有权限访问哪个数据库。
mysql.tables_priv
表:(表层权限)
- 存储表级别的权限信息,包括哪个用户有权限对哪个表进行操作(例如 SELECT、INSERT、UPDATE、DELETE)。
mysql.columns_priv
表:(字段层权限)
- 记录列级别的权限信息,包括哪个用户有权限访问表的哪些列。
三.?数据库的表管理
3.1.三大范式
数据库设计中的三大范式(Normal Forms)是一组规范,用于确保数据库表的结构具有最佳的组织和关联性,以减少数据冗余和提高数据的一致性。
第一范式:列不可再分(原子性) 例如:详细地址:湖南省长沙市岳麓区浪琴湾清水27栋
- 数据表中的每个列都包含原子性的值,不能再分解为更小的数据单元。
- 确保每个单元格只包含一个值,而不是多个值的列表或集合。
第二范式:主键约束 例如:订单项表设计:id、单价数量、小计
- 数据表必须符合第一范式,且表中的非主键列完全依赖于整个主键,而不是仅依赖于主键的一部分。
- 主要解决部分依赖的问题。
第三范式:外键约束? 例如:患者id、患者姓名同时存在于一张关联表中
- 数据表必须符合第二范式,且表中的非主键列之间不能存在传递依赖关系。
- 主要解决传递依赖的问题。
3.2.基本数据类型
数据库中的基本数据类型通常包括数值型、字符型、日期/时间型等。不同的数据库系统可能支持略有不同
? ? ? ? ?整数 | ????????????????????????????????????????????????tinyint8位(-128~127) |
????????????????????????????????????????smallint16位(-32768~32767) | |
????????????????????????????????mediumint24位(-8388608~8388607) | |
????????????????????????????????????????????????int32位大约正21亿 | |
????????????????????????????????????????????????????????bigint64位 |
实数(带有小数点) | ????????????????????????????????????????????????????????float4个字节 |
????????????????????????????????????????????????????????double8个字节 | |
????????????????????????????????????????????????decimal最多允许65个数字 |
字符串 | ? ? ? ? ? ? ?Char | 定长,MySQL根据定义字符串的长度一次分配足够的空间 |
适用场景:较短的字符串,且所有值接近同一长度 | ||
? ? ? ? ? ? varchar | 比定长类型节约空间 | |
适用场景:字符串的最长长度比评估长度大很多,列的更新较少 | ||
缺点:频繁修改,且字符串的长度变化大时,可能出现页分裂 |
?????text&blob | ? ? ? text存储字符数据 | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? tinytext |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? smalltext | ||
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? mediumtext | ||
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? text | ||
????????????????????????????????????????longtext | ||
??????blob存储二进制数据 | ????????????????????????????????????????tinyblob | |
????????????????????????????????????????smallblob | ||
????????????????????????????????????????mediumblob | ||
????????????????????????????????????????blob | ||
????????????????????????????????????????longblob |
日期时间 | ????????????????datatime | 精度:秒 |
与时区无关,8个字节存储空间 | ||
范围:1001至9999年 | ||
????????????????timestamp | 保存1970年1月1日午夜以来的秒数 | |
占用4个字节存储空间 | ||
范围:1970年至2038年 | ||
与时区有关 | ||
默认为NOTNULL | ||
通常尽量使用timestamp | ||
精度:秒 | ||
data | yyyy:MM:dd | |
time | HH:mm:ss |
选中标识符 | 用来进行关联操作 |
在其他表中作为外键 | |
-整型通常是标识列的最好选择 | |
-相关的表中使用相同的数据类型 | |
-尽量避免字符串作为标识列,尤其是随机生成的字符串,(如:UUID)导致insert与select都很慢-----------插入值被随机写到索引的不同位置,inser慢,容易导致页分裂,磁盘随机读取 逻辑上相邻的行被分布在磁盘和内存的不同地方,select慢 是MySQL查询缓存失效 如果需要存储UUID,则应将“-”去除 |
四.账号管理
查询用户 :
SELECT*from user
查看用户常用信息:
select host,user from user,
删除用户(慎用):
#命令: dropuser用户名;
#drop user Is;
权限操作
设置权限:
- 角色分配:?通常,权限通过角色进行管理。首先,定义不同的角色,并将相应的权限分配给这些角色。
- 直接分配权限:?在某些情况下,可能需要直接将权限授予特定的用户,而不通过角色。这样的直接分配可以是临时的或特殊情况下的需求。
#语法: grantprvilegesondatabasename.tablenametousername@'host;
#给zs用户赋予数据库db_xiaoli中的表t_p1_user查询权限
grant SELECT on db_xiaoli.t_p1_user to zs@%;
#给zs用户赋予数据库db_xiaoli中的表t_p1_user修改权限
grant UPDATE on db_xiaoli.t_p1_user to zs@'%'
#给zs用户赋予数据库db_xiaoli中所有表查询权限
grant SELECT on db_xiaoli.*to zs@'%';
#给zs用户赋予数据库db_xiaoli中所有表所有权限
grant ALL on db_xiaoli.*to zs@%';
撤销权限:
- 从角色中移除:?如果用户不再需要某些权限,管理员可以从其角色中移除这些权限。
- 直接取消权限:?对于直接分配的权限,管理员可以直接取消授予用户的特定权限。
查看用户权限:
- 角色查看:?管理员通常可以查看用户分配的角色,从而了解用户拥有的权限。
- 权限列表查看:?管理员可以查看用户直接被授予的权限列表,以便更详细地了解其访问权限。
- 审计日志:?系统可能记录了用户的权限使用情况,管理员可以通过审计日志来检查用户的活动和权限变更历史。
#命令:showgrantsfor用户名
show grantssfor zs'@%
五.思维导图
????????????????????????????????好啦今天就到这里了哦!!!希望能帮到你哦!!!
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!