MySQL OCP888题解061-库表访问权限的激活时机

Posted 2023-03-30 oddrock

文章目录

• 1、原题
• • 1.1、英文原题
  • 1.2、中文翻译
  • 1.3、答案
• 2、题目解析
• • 2.1、题干解析
  • 2.2、选项解析
• 3、实验
• • 3.1、实验1
  • • 3.1.1、实验目的
    • 3.1.2、实验前准备
    • 3.1.3、实验步骤
    • 3.1.4、实验结论
• 4、总结

1、原题

1.1、英文原题

You are contacted by a user who does not have permission to access a database table.
You determine after investigation that this user should be permitted to have access and so you execute a GRANT statement to enable the user to access the table.
Which statement describes the activation of that access for the user?
A、The access does not take effect until the user logs out and back in.
B、The access does not take effect until the next time the server is started.
C、The access is available immediately.
D、The access does not take effect until you issue the FLUSH PRIVILEGES statement.

1.2、中文翻译

一个没有访问数据库表权限的用户与您联系。
您在调查后确定应该允许该用户访问，因此您执行GRANT语句以允许用户访问该表。
哪个语句描述了用户对该访问的激活？
A、 直到用户登出并重新登录后，访问才会生效。
B、 直到下次启动服务器时，访问才会生效。
C、 访问立即可用。
D、 直到您发出FLUSH PRIVILEGES语句时，访问才会生效。

1.3、答案

C

2、题目解析

2.1、题干解析

本题考察对用户的库表访问权限进行授权的生效时机。

2.2、选项解析

1. mysql对用户授权可以访问指定库表时，是立即生效的。即使用户当前会话是在授权前打开的，也可以立即操作新授权的库表。因此选项C正确。

3、实验

3.1、实验1

3.1.1、实验目的

验证对用户的授权某个库的权限可以即时生效。

3.1.2、实验前准备

已安装好的MySQL并已运行。

3.1.3、实验步骤

1. 会话1：用管理员，先删除所有可能存在的数据库和用户，然后创建两个数据库d1、d2，在两个库中分别各建表t1、t2，再创建一个用户u1，将其中一个数据库d1授权给该用户。

mysql> DROP DATABASE IF EXISTS d1;
mysql> DROP DATABASE IF EXISTS d2;
mysql> DROP USER IF EXISTS u1;
mysql> CREATE DATABASE d1;
mysql> CREATE DATABASE d2;
mysql> CREATE TABLE d1.t1(id INT);
mysql> CREATE TABLE d2.t2(id INT);
mysql> CREATE USER u1 IDENTIFIED BY '000000';
mysql> GRANT SELECT ON d1.* TO u1;

2. 会话2：启动一个新会话，用u1用户登录，可以访问d1库，不能访问d2库

mysql> SELECT * FROM d1.t1;
Empty set (0.00 sec)
mysql> SELECT * FROM d2.t2;
ERROR 1142 (42000): SELECT command denied to user 'u1'@'localhost' for table 't2'

3. 会话1：将d2库也授权给u1用户

mysql> GRANT SELECT ON d2.* TO u1;

4. 会话2：在刚才的会话2里发现d2也可以查询了。

mysql> SELECT * FROM d1.t2;
Empty set (0.00 sec)

3.1.4、实验结论

MySQL对用户授权可以访问指定库表时，是立即生效的。即使用户当前会话是在授权前打开的，也可以立即操作新授权的库表。

4、总结

1. MySQL对用户授权可以访问指定库表时，是立即生效的。即使用户当前会话是在授权前打开的，也可以立即操作新授权的库表。

MySQL OCP888题解063-突然变慢的可能原因

文章目录

• 1、原题
• • 1.1、英文原题
  • 1.2、中文翻译
  • 1.3、答案
• 2、题目解析
• • 2.1、题干解析
  • 2.2、选项解析
• 3、总结

1、原题

1.1、英文原题

What are three typical causes of MySQL becoming suddenly slow or unavailable?
A、OPTIMIZE TABLE is not executed for the InnoDB tables.
B、A configuration change was made.
C、The hardware includes a single point of failure.
D、The MySQL Query Cache is disabled.
E、The application executes a new untested query.
F、Monitoring has not enabled Performance Schema instruments.

1.2、中文翻译

MySQL突然变慢或不可用的三个典型原因是什么？
A、 对于InnoDB表，不执行OPTIMIZE TABLE。
B、 进行了配置更改。
C、 硬件包括一个单点故障。
D、 MySQL查询缓存已禁用。
E、 应用程序执行一个新的未经测试的查询。
F、 监视尚未启用性能架构工具。

1.3、答案

2、题目解析

2.1、题干解析

本题考查MySQL性能影响的因素。

2.2、选项解析

1. OPTIMIZE TABLE会让表的统计信息变准，更有利于索引的选择等优化措施。但由于表的统计信息是随着数据量逐步变化的，并不会突然变差，所以不符合题干说的突然变慢或不可用这一点，所以选项A错误。
2. Query Cache已经被废弃了，而且本身作用不大，所以不会突然影响性能，选项D是错误的。
3. 监控更不会影响性能，所以选项F是错误的。

3、总结

1. OPTIMIZE TABLE会让表的统计信息变准，更有利于索引的选择等优化措施。
2. Query Cache已经被废弃了，而且本身作用不大。
3. MySQL的performance_schema等监控不会影响性能和正常运行。