更新：

进一步的调查显示，Question中描述的问题，以及我对它的最初回应（下面）可能与 * 表mysql.event* 的定义错误有关。在我的例子中，我有1）从MySQL 5.7.33加载一个完整的转储（包括 mysql 数据库）到新安装的MariaDB10.5.9; 2）发现this was not a good idea; 3）编辑了我的转储文件，以排除mysql数据库，4）重复加载而不删除任何数据库或配置。
这导致数据库正常运行，但是（除了本问题中描述的问题）a）/usr/sbin/mariadbd --verbose --help会尝试运行数据库服务器而不是打印帮助，b）启动时总是出现以下错误：

Apr 05 08:52:46 xxx mariadbd[22668]: 2021-04-05  8:52:46 0 [ERROR] Incorrect definition of table mysql.event: expected column 'sql_mode' at position 14 to have type set('REAL_AS_FLOAT','PIPES_AS_CONCAT','ANSI_QUOTES','IGNORE_SPACE','IGNORE_BAD_TABLE_OPTIONS','ONLY_FULL_GROUP_BY','NO_UNSIGNED_SUBTRACTION','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_FIELD_OPTIONS','MYSQL323','MYSQL40','ANSI','NO_AUTO_VALUE_ON_ZERO','NO_BACKSLASH_ESCAPES','STRICT_TRANS_TABLES','STRICT_ALL_TABLES','NO_ZERO_IN_DATE','NO_ZERO_DATE','INVALID_DATES','ERROR_FOR_DIVISION_BY_ZERO','TRADITIONAL','NO_AUTO_CREATE_USER','HIGH_NOT_PRECEDENCE','NO_ENGINE_SUBSTITUTION','PAD_CHAR_TO_FULL_LENGTH','EMPTY_STRING_IS_NULL','SIMULTANEOUS_ASSIGNMENT'), found type set('REAL_AS_FLOAT','PIPES_AS_CONCAT','ANSI_QUOTES','IGNORE_SPACE','NOT_USED','ONLY_FULL_GROUP_BY','NO_UNSIGNED_SUBTRACTION','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_FIELD_OPTIONS','MYSQL323','MYSQL40','ANSI','NO_AUTO_VALUE_ON_ZERO','NO_B
Apr 05 08:52:46 xxx mariadbd[22668]: 2021-04-05  8:52:46 0 [ERROR] mariadbd: Event Scheduler: An error occurred when initializing system tables. Disabling the Event Scheduler

字符串
今天，我能够纠正这些问题（在Amazon Linux 2下）：
1.卸载MariaDB服务器和MariaDB客户端
1.删除/etc/my.*
1.删除/var/lib/mysql
1.重新安装MariaDB服务器和MariaDB客户端
1.重新加载数据库转储，再次省略MySQL数据库的转储
在这一点上，我不仅有干净的数据库启动和正确的/usr/sbin/mariadbd --verbose --help操作，我还发现**select * from mysql.user工作正常！**
因此，无法从 mysql.user 中进行选择的问题似乎并不像我最初认为的那样，是由于 mysql.user 从表到视图的变化，而是由于一些与我的“不正确”数据库迁移有关的其他问题。

我的最初答案：

（仅作为参考）
经过大量的研究，我至少找到了这个问题的一部分答案：

tl;dr：select * from mysql.global_priv则每个用户show grants for 'XXX'@'localhost';

较长版本，从Authentication in MariaDB 10.4 — Understanding the Changes开始：
密码存储已更改。所有用户帐户、密码和全局权限现在都存储在mysql.global_priv表中。mysql.user表发生了什么？它仍然存在，并且有与以前完全相同的列集，但它mysql.global”
上面提到的文章不仅提供了“what”，还提供了“why”。我并不完全同意。特别是声明 * 旧的mysql.user表仍然存在，你可以像以前一样从它中选择 *，但你不能（因此这个问题）。尽管如此，我还是松了一口气，从MariaDB中找到了一个相对连贯的解释。
最后，这里有一个例子：

MariaDB [(none)]> select * from mysql.global_priv\G
*************************** 1. row ***************************
Host: localhost
User: mariadb.sys
Priv: {"access":0,"plugin":"mysql_native_password","authentication_string":"","account_locked":true,"password_last_changed":0}
*************************** 2. row ***************************
Host: localhost
User: root
Priv: {"access": 1844674407370915, "plugin": "mysql_native_password", "authentication_string": "*9A87226E872127C756290C504DB5D9076E", "auth_or": [{}, {"plugin": "unix_socket"}], "password_last_changed": 1617303275}
*************************** 3. row ***************************
Host: localhost
User: mysql
Priv: {"access":1844674407371615,"plugin":"mysql_native_password","authentication_string":"invalid","auth_or":[{},{"plugin":"unix_socket"}]}
*************************** 4. row ***************************

MariaDB [(none)]> show grants for 'root'@'localhost'\G
*************************** 1. row ***************************
Grants for root@localhost: GRANT ALL PRIVILEGES ON *.* TO `root`@`localhost` IDENTIFIED VIA mysql_native_password USING '*9A87226E872127C756290C5BF177504DB5D9076E' OR unix_socket WITH GRANT OPTION
*************************** 2. row ***************************
Grants for root@localhost: GRANT PROXY ON ''@'%' TO 'root'@'localhost' WITH GRANT OPTION

型

您还可以使用以下命令插入缺少的权限：

INSERT INTO `tables_priv` (`Host`, `Db`, `User`, `Table_name`, `Grantor`, `Timestamp`, `Table_priv`, `Column_priv`) VALUES ('localhost','mysql','mariadb.sys','global_priv','root@localhost','0000-00-00 00:00:00','Select,Delete','');

字符串