Mysql8.0掉电数据库瓦解启动失败-Can‘t open and lock privilege tables: ...

昨天突然收到数据库启动不了的通知，要紧急处理。
查看错误日志报错如下：
Can't open and lock privilege tables: Table 'mysql.user' doesn't exist
2024-04-17T09:47:27.329763Z 0 [ERROR] [MY-010952] [Server] The privilege system failed to initialize correctly. For complete instructions on how to upgrade MySQL to a new version please see the 'Upgrading MySQL' section from the MySQL manual.
Could not open the mysql.plugin table. Please perform the MySQL upgrade procedure.
解决方案步调：
 1. 修改my.cnf配置文件，设置为无密码登录模式，然后启动。
    vi /etc/my.cnf 
      [mysqld]
     skip-grant-tables
  2、启动mysql， service mysqld start   

启动成功！！！！
针对Mysql8.0 不绝没有深入的研究，感觉跟5.6~5.7区别不大。事实证明差距还是很大的。于是借此时机对Mysql8.0跟新的改动深入的学习一下。
Mysql8.0的变革有以下8大块内容：
1. 数据字典变动

2.caching_sha2_password作为首先身份验证插件

3.配置变动

4.服务器变动

5.InnoDB的变革

6.SQL更改

7. 更改了服务器默认值

8.有效的性能回归

下面详细的介绍以上8块内容。

• 数据字典变动​​​​​​​
  

MySQL Server 8.0包罗一个全局数据字典，此中包罗事务表中数据库对象的信息。在以前的MySQL系列中，字典数据存储在元数据文件和非事务性系统表中。
启用数据字典的服务器会带来一些一般性操作上的差异；官方文档阅第16.7节“数据字典使用差异”。详细解释如下：
使用启用数据字典的MySQL服务器与没有数据字典的服务器相比，会导致一些操作上的差异：

• 1. 以前，启用 innodb_read_only 系统变量只阻止了对 InnoDB 存储引擎的表举行创建和删除操作。从 MySQL 8.0 开始，启用 innodb_read_only 会阻止所有存储引擎的这些操作。任何存储引擎的表创建和删除操作都会修改 mysql 系统数据库中的数据字典表，但这些表使用的是 InnoDB 存储引擎，在启用 innodb_read_only 时无法修改。对于需要修改数据字典表的其他表操作也实用相同的原则。
  

   例如：

1. ANALYZE TABLE 失败，因为它会更新存储在数据字典中的表统计信息。
2. ALTER TABLE tbl_name ENGINE=engine_name 失败，因为它会更新存储在数据字典中的存储引擎指定。

复制代码

• 注意：启用 innodb_read_only 对 mysql 系统数据库中的非数据字典表也具有重要影响。
  

  

• 2. 以前，mysql 系统数据库中的表可以被 DML 和 DDL 语句看到。从 MySQL 8.0 开始，数据字典表是不可见的，不能直接修改或查询。然而，在大多数情况下，存在相应的 INFORMATION_SCHEMA 表，可以代替直接查询。这使得在服务器开辟举行时可以更改底层的数据字典表，同时保持稳固的 INFORMATION_SCHEMA 接口供应用步伐使用。
  
• 3. MySQL 8.0中的INFORMATION_SCHEMA表与数据字典紧密相连，导致了几种使用上的差异：
  

   差异1：
以前，在STATISTICS 和 TABLES 表中的INFORMATION_SCHEMA查询直接从存储引擎中检索表统计信息。从MySQL 8.0开始，默认情况下使用缓存的表统计信息。information_schema_stats_expiry 系统变量界说了缓存的表统计信息过期之前的时间段。默认值为 86400 秒（24 小时）。 （要随时更新给定表的缓存值，请使用 ANALYZE TABLE。）如果没有缓存的统计信息或统计信息已过期，则在查询表统计列时从存储引擎中检索统计信息。要始终直接从存储引擎检索最新的统计信息，请将information_schema_stats_expiry 设置为 0。有关更多信息，请参阅第10.2.3节“优化 INFORMATION_SCHEMA 查询”。
  差异2：一些INFORMATION_SCHEMA表是对数据字典表的视图，这使得优化器可以使用这些底层表上的索引。因此，根据优化器的选择，INFORMATION_SCHEMA查询结果的行序次可能与以前的结果差别。如果查询结果必须具有特定的行排序特性，请包罗ORDER BY子句。
  差异3：
        对INFORMATION_SCHEMA表的查询可能以差别的巨细写情势返回列名，与之前的MySQL系列差别。应用步伐应以不区分巨细写的方式测试结果集的列名。如果这种方法不可行，可以使用在选择列表中返回所需巨细写情势的列别名作为一种解决方法。例如：

1. SELECT TABLE_SCHEMA AS table_schema, TABLE_NAME AS table_name
2. FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'users';

复制代码

mysqldump 和 mysqlpump 不再在命令行上明确命名时转储INFORMATION_SCHEMA数据库。

1. CREATE TABLE dst_tbl LIKE src_tbl

复制代码

要求src_tbl是一个基表，并且如果它是一个在数据字典表上的视图的INFORMATION_SCHEMA表，则会失败。
  以前，从INFORMATION_SCHEMA表中选择的结果集列的结果集标题使用查询中指定的大写情势。这个查询生成一个具有table_name标题的结果集：

1. SELECT table_name FROM INFORMATION_SCHEMA.TABLES;

复制代码

从MySQL 8.0开始，这些标题被大写化；前面的查询生成一个具有TABLE_NAME标题的结果集。如果需要，可以使用列别名来实现差别的巨细写情势。例如：

1. SELECT table_name AS 'table_name' FROM INFORMATION_SCHEMA.TABLES;

复制代码

差异4：
数据目次影响了mysqldump和mysqlpump从mysql系统数据库中转储信息的方式：
   4.1 以前，可以转储mysql系统数据库中的所有表。从MySQL 8.0开始，mysqldump和mysqlpump只转储该数据库中的非数据字典表。
   4.2 以前，当使用--all-databases选项时，不需要--routines和--events选项来包括存储过程和事件：转储包括了mysql系统数据库，因此也包括了包罗存储过程和事件界说的proc和event表。从MySQL 8.0开始，不再使用event和proc表。相应对象的界说存储在数据字典表中，但这些表不会被转储。要在使用--all-databases举行的转储中包括存储过程和事件，请明确使用--routines和--events选项。
   4.3 以前，--routines选项需要对proc表的SELECT权限。从MySQL 8.0开始，不再使用该表；--routines需要全局SELECT权限。
   4.4 以前，可以通过转储proc和event表来一起转储存储过程和事件界说以及它们的创建和修改时间戳。从MySQL 8.0开始，不再使用这些表，因此无法转储时间戳。
  

• 4. 以前，创建包罗非法字符的存储过程会产生警告。从MySQL 8.0开始，这将被视为错误。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。