回答来自于问答智囊团成员：王文安@DBA 专栏：https://cloud.tencent.com/developer/user/7566357 原因剖析 实际上是MySQL 8.0为了提高information_schema的查询效率，将表和统计信息放入内部的统计信息缓存起来，缓存时间由参数information_schema_stats_expiry决定，至少为86400s；如果想获取最新的统计信息，可以通过如下两种方式： （1）分析表进行表分析 （2）设置information_schema_stats_expiry = 0 继续探索 那么统计信息不准确，会带来哪些影响呢？或者会影响执行计划呢？然后我们再次进行测试 测试1：表test记录数100，表sbtest1记录数100w 执行如下SQL，查看执行计划，走的是NLJ，小表test作为驱动表（全表扫描），大表sbtest1作为被驱动表（主键关联），执行效率很快 mysql >从测试中选择count （* ） ；+ - - - - - + | 数（* ）| + - - - - - + | 100 | + - - - - - + 1行中集合（0.00秒） mysql >从sbtest1选择计数（* ） ; + - - - - - + | 数（* ）| + - - - - - + | 1000000 | + - - - - - + 1行中集合（0.02秒） mysql >从table_name = 'test'的表中选择table_schema ， table_name ， table_rows ; + - - - - - - - + - - - - - - + - - - - - - + | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | + - - - - - - - + - - - - - - + - - - - - - + | 测试 | 测试 | 100 | + - - - - - - - + - - - - - - + - - - - - - + 1行中 集合 （0.00秒） mysql >从table_name = 'sbtest1'的表中选择table_schema ， table_name ， table_rows ; + - - - - - - - + - - - - - - + - - - - - - + | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | + - - - - - - - + - - - - - - + - - - - - - + | 测试 | sbtest1 | 947468 | + - - - - - - - + - - - - - - + - - - - - - + 1行中 集合 （0.01秒） mysql >选择t 。* 来自于t的测试t内部联接sbtest1 t1 。id = t1 。id在哪里t 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977'和t1 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977' ; + - - + - - - - + - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | id | k | c | 垫 | + - - + -- - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | 1 | 501885 | 08566691963 - 88624912351 - 16662227201 - 46648573979 -64646226163 - 77505759394 - 75470094713 - 41097360717 - 15161106334 - 50535565977 | 63188288836 - 92351140030 - 06390587585 - 66802097351 - 49282961843 | + - - + - - - - + - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - + 1行中 集合 （0.00秒） mysql >说明选择t 。* 来自于t的测试t内部联接sbtest1 t1 。id = t1 。id在哪里t 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977'和t1 。Ç = ' 08566691963 - 88624912351 - 16662227201 - 4664 + - - + - - - - - - - + - - -- + - - - - - - + - - - - + - - - - - - - - + - - - - - + - - - - - + - - - - - - + - - - + - - - - - + - - - - - -- + | id | select_type | 桌子| 隔板| 键入 | 可能的钥匙| 关键 | key_len | 参考 | 行| 过滤| 额外 | + - - + - - - - - - - + - - - - + - - - - - - + -- - - + - - - - - - - - + - - - - - + - - - - - + - - - - - - - + - - - + - - - - - + - - - - - - - + | 1 | SIMPLE | t |NULL | 全部 | 主要 | NULL | NULL | NULL | 100 | 10.00 | 使用Where | | 1 | SIMPLE | t1 | NULL | eq_ref | 主要 | 主要| 4 | 测试。Ť 。id | 1 | 10.00 | 使用Where | + - -+ - - - - - - - + - - - - + - - - - - - + - - - - + - - - - - - - - - + - - - - - + - - - - - + - - - - - - + - - - +- - - - - + - - - - - - - + 2行中 集合， 1个 警告 （0.00秒） 测试2：表test记录数1000w左右，表sbtest1记录数100w 再次执行SQL，查看执行计划，走的也是NLJ，相对小表sbtest1作为驱动表，大表测试作为被驱动表，也是正确的执行计划 mysql >从测试中选择count （* ） ；+ - - - - - + | 数（* ）| + - - - - - + | 10000100 | + - - - - - + 1行中集合（0.33秒） mysql >从sbtest1选择计数（* ） ; + - - - - - + | 数（* ）| + - - - - - + | 1000000 | + - - - - - + 1行中集合（0.02秒） mysql >从table_name = 'test'的表中选择table_schema ， table_name ， table_rows ; + - - - - - - - + - - - - - - + - - - - - - + | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | + - - - - - - - + - - - - - - + - - - - - - + | 测试 | 测试 | 100 | + - - - - - - - + - - - - - - + - - - - - - + 1行中 集合 （0.00秒） mysql >从table_name = 'sbtest1'的表中选择table_schema ， table_name ， table_rows ; + - - - - - - - + - - - - - - + - - - - - - + | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | + - - - - - - - + - - - - - - + - - - - - - + | 测试 | sbtest1 | 947468 | + - - - - - - - + - - - - - - + - - - - - - + 1行中 集合 （0.01秒） mysql >选择t 。* 来自于t的测试t内部联接sbtest1 t1 。id = t1 。id在哪里t 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977'和t1 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977' ; + - - + - - - - + - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | id | k | c | 垫 | + - - + -- - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | 1 | 501885 | 08566691963 - 88624912351 - 16662227201 - 46648573979 -64646226163 - 77505759394 - 75470094713 - 41097360717 - 15161106334 - 50535565977 | 63188288836 - 92351140030 - 06390587585 - 66802097351 - 49282961843 | + - - + - - - - + - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - + 1行中 集合 （0.37秒） mysql >说明选择t 。* 来自于t的测试t内部联接sbtest1 t1 。id = t1 。id在哪里t 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977'和t1 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977' ; + - - + - - - - - - - + - - -- + - - - - - - + - - - - + - - - - - - - - + - - - - - + - - - - - + - - - - - - + - - - - + - - - - - + - - - - - -- - + | id | select_type | 桌子| 隔板| 键入 | 可能的钥匙| 关键 | key_len | 参考 | 行 | 过滤| 额外 | + - - + - - - - - - - + - - - - + - - - - - - +- - - - + - - - - - - - - + - - - - - + - - - - - + - - - - - - - + - - - - + - - - - - + - - - - - - - + | 1 | SIMPLE |t1 | NULL | 全部 | 主要 | NULL | NULL | NULL | 947468 | 10.00 | 使用Where | | 1 | SIMPLE | t | NULL | eq_ref | 主要 | 主要| 4 | 测试。T1 。id | 1 | 10.00 | 使用Where | + - - + - - - - - - - + - - - - + - - - - - - + - - - - + - - - - - - - - + - - - - - + - - - - - + - - - - - - + - --- - - + - - - - - + - - - - - - - + 2行中集合，1个警告（0.01秒） 为什么优化器没有选择错误的执行计划呢？之前文章也提过，MySQL 8.0是将元数据信息存放在MySQL库下的数据字典表里，information_schema库只是提供相对方便的视图供用户查询，所以优化器在选择执行计划时，会从数据字典表中获取统计信息，生成正确的执行计划。 总结 MySQL 8.0为了提高information_schema的查询效率，将视图和表的内部信息统计缓存起来，缓存时间由参数information_schema_stats_expiry决定（建议设置该参数为0）；这可能会导致用户查询上方视图时，无法获取最新，准确的统计信息，但并不会影响执行计划的选择。

回答来自于问答智囊团成员：王文安@DBA 专栏：https://cloud.tencent.com/developer/user/7566357 怎么看懂 CPU 使用率 以 Linux 的 top 命令为例，效果如下： 📷 Top 命令 在 %CPU 这一列就展示了 CPU 的使用情况，百分比指代的是总体上占用的时间百分比： %us：表示用户进程的 CPU 使用时间（没有通过 nice 调度） %sy：表示系统进程的 CPU 使用时间，主要是内核使用。 %ni：表示用户进程中，通过 CPU 调度（nice）过的使用时间。 %id：空闲的 CPU 时间 %wa：CPU 运行时在等待 IO 的时间 %hi：CPU 处理硬中断花费的时间 %si：CPU 处理软中断花费的时间 %st：被虚拟机偷走的 CPU 时间 通常情况下，我们讨论的 CPU 使用率过高，指的是 %us 这个指标，监控里面的 CPU 使用率通常也是这个值（也有用其他的方法计算出来的，不过简单起见，不考虑其他的情况 ）。其他几个指标过高也代表出 MySQL 的状态异常，简单起见，这里主要还是指 %us 过高的场景。 MySQL 和线程 MySQL 是单进程多线程的结构，意味着独占的 MySQL 服务器里面，只能用 top 命令看到一行数据。 📷 TOP 命令效果 这里能看到的是 MySQL 的进程 ID，如果要看到线程的情况，需要用top -H 📷 TOP 命令效果 在这里能看到的是 MySQL 各个线程的 ID，可以看到 MySQL 在启动之后，会创建非常多的内部线程来工作。 这些内部线程包括 MySQL 自己用来刷脏，读写数据等操作的系统线程，也包括处理用户 SQL 的线程，姑且叫做用户线程吧。用户线程有一个特殊的地方：程序端发送到 MySQL 端的 SQL，只会由一个用户线程来执行（one-thread-per-connection），所以 MySQL 在处理复杂查询的时候，会出现“一核有难，多核围观”的尴尬现象。 参考 %us 的定义，对于 Linux 系统来说，MySQL 进程和它启动的所有线程都不算内核进程，因此 MySQL 的系统线程和用户线程在繁忙的时候，都会体现在 CPU 使用率的 %us 指标上。 MySQL 干什么的时候，CPU 会 100% 从前文的分析来看，MySQL 主要是两类线程占用 CPU：系统线程和用户线程。因此 MySQL 独占的服务器上，只需要留意一下这两类线程的情况，就能 Cover 住绝大部分的问题场景。 系统线程 在实际的环境中，系统线程遇到问题的情况会比较少，一般来说，多个系统线程很少会同时跑满，只要服务器的可用核心数大于等于 4 的话，一般也不会遇到 CPU 100%，当然有一些 bug 可能会有影响，比如这个： 📷 MySQL BUG 虽然情况比较少，但是在面对问题的常规排查过程中，系统线程的问题也是需要关注的。 用户线程 提到用户线程繁忙，很多时候肯定会第一时间凭经验想到慢查询。确实 90% 以上的时候都是“慢查询”引起的，不过作为方法论，还是要根据分析再去得出结论的~ 参考 us% 的定义，是指用户线程占用 CPU 的时间多少，这代表着用户线程占用了大量的时间。 一方面是在进行长时间的计算，例如：order by，group by，临时表，join 等。这一类问题可能是查询效率不高，导致单个 SQL 语句长时间占用 CPU 时间，也有可能是单纯的数据量比较多，导致计算量巨大。另一方面是单纯的 QPS 压力高，所以 CPU 的时间被用满了，比如 4 核的服务器用来支撑 20k 到 30k 的点查询，每个 SQL 占用的 CPU 时间并不多，但是因为整体的 QPS 很高，所以 CPU 的时间被占满了。 怎么定位问题？ 分析完之后，就要开始实战了，这里根据前文的分析给出一些经典的 CPU 100% 场景，并给出简要的定位方法作为参考。 PS：系统线程的 bug 的场景 skip，以后有机会再作为详细的案例来分析。 慢查询 在 CPU 100% 这个问题已经发生之后，真实的慢查询和因为 CPU 100% 导致被影响的普通查询会混在一起，难以直观的看 processlist 或者 slowlog 来发现元凶，这时候就需要一些比较明确的特征来进行甄别。 从前文的简单分析可以看出来，查询效率不高的慢查询通常有以下几种情况： 全表扫描：Handler_read_rnd_next 这个值会大幅度突增，且这一类查询在 slowlog 中 row_examined 的值也会非常高。 索引效率不高，索引选错了：Handler_read_next 这个值会大幅度的突增，不过要注意这种情况也有可能是业务量突增引起的，需要结合 QPS/TPS 一起看。这一类查询在 slowlog 中找起来会比较麻烦，row_examined 的值一般在故障前后会有比较明显的不同，或者是不合理的偏高。 比如数据倾斜的场景，一个小范围的 range 查询在某个特定的范围内 row_examined 非常高，而其他的范围时 row_examined 比较低，那么就可能是这个索引效率不高。 排序比较多：order by，group by 这一类查询通常不太好从 Handler 的指标直接判断，如果没有索引或者索引不好，导致排序操作没有消除的话，那么在 processlist 和 slowlog 通常能看到这一类查询语句出现的比较多。 当然，不想详细的分析 MySQL 指标或者是情况比较紧急的话，可以直接在 slowlog 里面用 rows_sent 和 row_examined 做个简单的除法，比如 row_examined/rows_sent > 1000 的都可以拿出来作为“嫌疑人”处理。这类问题一般在索引方面做好优化就能解决。 PS：1000 只是个经验值，具体要根据实际业务情况来定。 计算量大 这一类问题通常是因为数据量比较大，即使索引没什么问题，执行计划也 OK，也会导致 CPU 100%，而且结合 MySQL one-thread-per-connection 的特性，并不需要太多的并发就能把 CPU 使用率跑满。这一类查询其实是是比较好查的，因为执行时间一般会比较久，在 processlist 里面就会非常显眼，反而是 slowlog 里面可能找不到，因为没有执行完的语句是不会记录的。 这一类问题一般来说有三种比较常规的解决方案： 读写分离，把这一类查询放到平时业务不怎么用的只读从库去。 在程序段拆分 SQL，把单个大查询拆分成多个小查询。 使用 HBASE，Spark 等 OLAP 的方案来支持。 高 QPS 这一类问题单纯的就是硬件资源的瓶颈，不论是 row_examined/rows_sent 的比值，还是 SQL 的索引、执行计划，或者是 SQL 的计算量都不会有什么明显问题，只是 QPS 指标会比较高，而且 processlist 里面可能什么内容都看不到，例如： 📷 processlist 总结一下 实际上 CPU 100% 的问题其实不仅仅是单纯的 %us，还会有 %io，%sys 等，这些会涉及到 MySQL 与 Linux 相关联的一部分内容，展开来就会比较多了。本文仅从 %us 出发尝试梳理一下排查&定位的思路和方法，在分析 %io，%sys 等方面的问题时，也可以用类似的思路，从这些指标的意义开始，结合 MySQL 的一些特性或者特点，逐步理清楚表象背后的原因。

相对于个人网站，建议多方式存储。将生成的 HTML 放到硬盘上，访问的时候直接从磁盘读取文件提交到客户浏览器，这样不需要做数据处理就能火速读取。如果自己修改，就读取富文本的数据。至于数据库存储的内容，建议就是纯文字，去掉所有的格式信息，用来检索文章用。 来源链接：https://www.zhihu.com/question/52717468/answer/320826784

简要分析 MySQL 在创建用户的时候，一般是需要指定用户名和来源 IP 的，比如： mysql> show grants for test@'%'; +----------------------------------+ | Grants for test@% | +----------------------------------+ | GRANT USAGE ON *.* TO 'test'@'%' | +----------------------------------+ 1 row in set (0.00 sec) 由于 Host 这个字段支持正则匹配，因此这个字段设置为 % 的时候，则代表所有的来源 IP 都能匹配到。 因为这个特性，所以有时候创建的账号会有如下的情况出现： +------+---------------+ | user | host | +------+---------------+ | test | % | | test | 10.104.% | | test | 10.104.56.136 | +------+---------------+ 参考官方文档的描述： When multiple matches are possible, the server must determine which of them to use. It resolves this issue as follows: 1.Whenever the server reads the user table into memory, it sorts the rows. 2.When a client attempts to connect, the server looks through the rows in sorted order. 3.The server uses the first row that matches the client host name and user name. The server uses sorting rules that order rows with the most-specific Host values first. 简而言之：MySQL 会按照 Host 的匹配精度，按降序排列同一个 Username 的所有账号，当 Client 端尝试登录 MySQL 的时候，会按照顺序依次这个 Username 下面所有的 Host 规则，直到匹配成功。 Host 这个字段不仅能填 IP，也能写域名，同样也能利用到正则表达式匹配： 📷 匹配示例 由于域名指向的 IP 受 DNS 的影响，因此多数时候会用 IP，一般来说需要 DNS 来屏蔽一些后端细节的时候才会用域名来作为 Host 字段的值。 测试一下 使用如下操作创建三个用户，密码不做区分： mysql> create user test@'%' identified by 'test'; Query OK, 0 rows affected (0.00 sec) mysql> create user test@'10.104.56.136' identified by 'test'; Query OK, 0 rows affected (0.00 sec) mysql> create user test@'10.104.%' identified by 'test'; Query OK, 0 rows affected (0.01 sec) mysql> mysql> mysql> mysql> select user,host from mysql.user where user='test' order by host desc; +------+---------------+ | user | host | +------+---------------+ | test | 10.104.56.136 | | test | 10.104.% | | test | % | +------+---------------+ 3 rows in set (0.00 sec) mysql> PS：order by desc 仅为展示上的考虑。 那么从两个不同的机器上（10.104.56.136 和 10.104.43.107）尝试登录 MySQL，按照文档的描述，匹配的优先级应该是：10.104.56.136->10.104.%->%。那么有一台服务器能完整匹配到 IP，另外一台服务器匹配到的应该是10.104.%。 实际操作一下看看效果： root@debian:~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.104.56.136 ......(省略) root@debian:~# mysql -h192.168.1.100 -utest -ptest ......(省略) Server version: 5.7.18-txsql-log 20200331 ......(省略) mysql> show grants; +----------------------------------------------+ | Grants for test@10.104.56.136 | +----------------------------------------------+ | GRANT USAGE ON *.* TO 'test'@'10.104.56.136' | +----------------------------------------------+ 1 row in set (0.00 sec) mysql> 在另外一台机器上： root@VM-43-107-debian:~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.104.43.107 ......(省略) root@debian:~# mysql -h192.168.1.100 -utest -ptest ......(省略) Server version: 5.7.18-txsql-log 20200331 ......(省略) mysql> show grants; +-----------------------------------------+ | Grants for test@10.104.% | +-----------------------------------------+ | GRANT USAGE ON *.* TO 'test'@'10.104.%' | +-----------------------------------------+ 1 row in set (0.00 sec) mysql> 换成本地的设备再试一下登录： Tomo@MacBook-Pro ~ % mysql -hgz-cdb.sql.tencentcdb.com -utest -ptest -P59888 ......(省略) Server version: 5.7.18-txsql-log 20200331 ......(省略) mysql> show grants; +----------------------------------+ | Grants for test@% | +----------------------------------+ | GRANT USAGE ON *.* TO 'test'@'%' | +----------------------------------+ 1 row in set (0.02 sec) mysql> 可以看到本地设备的 IP 由于和前两个匹配规则不一致，所以最后匹配到了 % 的这个账号。 总结一下 作为比较保险的办法，尽量少用 Host 来区分不同的账号，直接用不同的 Username 会比较好管理和维护，如果一定需要用 Host 来区分，那么至少也要用不同的密码，防止匹配到了错误的用户，导致权限不足引起业务上的问题。 课外题 localhost 和 127.0.0.1 算是常用的两个 Host，可以作为实践内容动手试一下，体验一下匹配的规律。在 MySQL 看来，精确的域名和精确的 IP 是同等地位的。

云主机配置VPN服务器通常涉及以下几个步骤： 1. **选择云服务提供商**：首先，你需要选择一个云服务提供商，如Vultr、腾讯云等。这些提供商提供了虚拟机，可以在其上安装和配置VPN服务器。 2. **创建虚拟机**：登录到云服务提供商的控制面板，创建一个新的虚拟机。选择操作系统（如Windows Server 2003、CentOS等）、配置（如CPU、内存、硬盘等）以及网络设置（如公网IP、内网IP等）。 3. **安装操作系统和必要的软件**：根据选择的操作系统，安装相应的系统镜像。然后，安装VPN服务器软件，如OpenVPN、SoftEther等。这些软件通常需要编译和安装，可能需要一些技术知识。 4. **配置VPN服务器**：根据VPN服务器的软件指南，配置服务器设置，如证书、用户账户、端口等。确保VPN服务器可以正常运行，并且可以从客户端设备连接。 5. **创建防火墙策略和VPN远程访问规则**：配置防火墙，允许VPN流量通过，同时阻止其他不必要的流量。这可以确保VPN连接的安全性和稳定性。 6. **配置用户和权限**：创建用户账户，并为每个用户分配VPN访问权限。这可以通过云服务提供商的控制面板或VPN服务器的配置工具完成。 7. **测试VPN连接**：从客户端设备尝试连接到VPN服务器。确保连接成功，并且可以访问内部网络资源。 8. **优化和监控**：根据需求，优化VPN服务器的性能，如调整内存分配、CPU使用率等。同时，监控VPN服务器的运行状态，确保其稳定可靠。 以上是云主机配置VPN服务器的基本步骤。具体的配置方法可能因VPN服务器软件、云服务提供商以及个人需求而有所不同。在配置过程中，建议参考官方文档和教程，以确保安全和稳定。

根据你提供的信息，这里有一些建议和可能的原因： 1. 检查服务器配置：确保服务器已经正确配置，包括端口、防火墙、虚拟主机等设置。检查服务器的错误日志，看是否有任何错误信息。 2. 检查数据库连接：确保你的网站源码中的数据库连接信息（如主机名、用户名、密码、数据库名等）是正确的。检查数据库服务器是否正在运行，以及网站源码是否有权限访问数据库。 3. 检查伪静态规则：确保你的伪静态规则设置正确。对于ThinkPHP，你可以在项目根目录下的`.htaccess`文件中找到伪静态规则。如果文件不存在，请创建一个并添加正确的规则。 4. 检查文件权限：确保你的网站源码和数据库文件具有正确的权限。通常，文件权限应设置为`644`，目录权限应设置为`755`。 5. 检查网站源码：检查你的网站源码中是否有语法错误、逻辑错误或其他问题。你可以在本地环境中测试网站，确保其正常运行。 6. 检查服务器资源：确保服务器具有足够的资源（如内存、CPU、磁盘空间等）来运行你的网站。如果服务器资源不足，可能导致服务器拒绝连接。 7. 检查服务器负载：如果服务器托管了多个网站或应用程序，确保服务器负载不过高。高负载可能导致服务器拒绝新的连接请求。 8. 检查服务器状态：确保服务器正在运行，并且没有崩溃或其他问题。你可以尝试重启服务器，看是否能解决问题。 如果以上建议都无法解决问题，请提供更多关于错误的详细信息，如错误日志、服务器配置等，以便我们能够更好地帮助你。

如何选择加密算法还是取决于用户及网站的需求来定。腾讯云服务器云加密主要采用对称加密算法，做加密权鉴处理；可防盗链。 加密算法主要分为以下几种： 1、对称加密算法 所谓对称，就是采用这种加密方法的双方使用方式用同样的密钥进行加密和解密。密钥是控制加密及解密过程的指令。算法是一组规则，规定如何进行加密和解密。 分类 常用的算法有：DES、3DES、AES等。 DES 全称为Data Encryption Standard，即数据加密标准，是一种使用密钥加密的块算法，1977年被美国联邦政府的国家标准局确定为联邦资料处理标准（FIPS），并授权在非密级政府通信中使用，随后该算法在国际上广泛流传开来。 3DES 即TripleDES，是DES向AES过渡的加密算法，它使用3条56位的密钥对数据进行三次加密。是DES的一个更安全的变形。它以DES为基本模块，通过组合分组方法设计出分组加密算法。比起最初的DES，3DES更为安全。 AES 全称为Advanced Encryption Standard，在密码学中又称Rijndael加密法，是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES，已经被多方分析且广为全世界所使用。 优缺点 对称加密算法的优点是算法公开、计算量小、加密速度快、加密效率高。 对称加密算法的缺点是在数据传送前，发送方和接收方必须商定好秘钥，然后使双方都能保存好秘钥。其次如果一方的秘钥被泄露，那么加密信息也就不安全了。另外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的唯一秘钥，这会使得收、发双方所拥有的钥匙数量巨大，密钥管理成为双方的负担。 应用 保存用户手机号、身份证等敏感但能解密的信息 2、非对称性加密算法 与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。 分类 常用的算法有：RSA、DSA、ECC等。 RSA 全称为Digital Signature Algorithm，是第一个能同时用于加密和数字签名的算法，也易于理解和操作。RSA是被研究得最广泛的公钥算法，从提出到现今的三十多年里，经历了各种攻击的考验，逐渐为人们接受，普遍认为是目前最优秀的公钥方案之一。 DSA 全称为Digital Encryption Standard，是基于整数有限域离散对数难题的，其安全性与RSA相比差不多。DSA的一个重要特点是两个素数公开，这样，当使用别人的p和q时，即使不知道私钥，你也能确认它们是否是随机产生的，还是作了手脚。RSA算法却做不到。 ECC 全称为Elliptic Curves Cryptography,，也叫椭圆加密算法，是一种公钥加密体制，最初由Koblitz和Miller两人于1985年提出，其数学基础是利用椭圆曲线上的有理点构成Abel加法群上椭圆离散对数的计算困难性。 与RSA，DSA相比，ECC有以下优点： 安全性高，有研究表示160位的椭圆密钥与1024位的RSA密钥安全性相同。 处理速度快，在私钥的加密解密速度上，ecc算法比RSA、DSA速度更快。 存储空间占用小。 带宽要求低. 优缺点 非对称加密与对称加密相比，其安全性更好：对称加密的通信双方使用相同的秘钥，如果一方的秘钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对秘钥，一个用来加密，一个用来解密，而且公钥是公开的，秘钥是自己保存的，不需要像对称加密那样在通信之前要先同步秘钥。 非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。 应用 一般用于签名和认证 3、散列算法 在信息安全技术中，经常需要验证消息的完整性，散列（Hash）函数提供了这一服务，它对不同长度的输入消息，产生固定长度的输出。这个固定长度的输出称为原输入消息的“散列”或“消息摘要”（Message digest）。 分类 常用的算法有：MD5、SHA、HMAC等。 MD5 全称为Message Digest Algorithm，即中文名为消息摘要算法第五版，为计算机安全领域广泛使用的一种散列函数，用以提供消息的完整性保护。 SHA 全称为Secure Hash Algorithm，即安全哈希算法，主要适用于数字签名标准（Digital Signature Standard DSS）里面定义的数字签名算法（Digital Signature Algorithm DSA）。有SHA-1，SHA-224，SHA-256，SHA-384，和SHA-512这几种单向散列算法，其中SHA-1已经不安全。 HMAC 全称为Hash Message Authentication Code，即散列消息鉴别码，主要是利用哈希算法，以一个密钥和一个消息为输入，生成一个消息摘要作为输出。一般的，消息鉴别码用于验证传输于两个共 同享有一个密钥的单位之间的消息。HMAC 可以与任何迭代散列函数捆绑使用。MD5 和 SHA-1 就是这种散列函数。HMAC 还可以使用一个用于计算和确认消息鉴别值的密钥。 应用 效验下载文件正确性，一般在网站上下载文件都能见到 存储用户敏感信息，如密码、 卡号等不可解密的信息 建议 AES采用128为即可，RSA建议采用1024位的数字，ECC建议采用160位。RSA加密字符长度有限制，一般采用AES+RSA方式组合使用。 误区 很多博客把Base64编码也当做一种加密算法来解释，这是不严谨的。Base64是没有可读性，但不代表这个编码就是加密的。加密需要保证没有密钥的人无法解密信息，更无法从密文中破解任何明文信息，但Base64可以很轻松的反编码。另外，Base64编码也显然没有用到密钥，不具有加密算法的安全性，所以，这个误区大家要纠正过来。

TXSQL是腾讯基础架构部数据库团队自研的MySQL分支，对腾讯云以及众多的内部业务提供了强大的数据库内核支撑。相比原生的MySQL，TXSQL在BINLOG复制和InnoDB存储引擎方面做了很多的优化，另外在Server层面也做了大量的工作。因此TXSQL拥有更好的性能，更好的稳定性和可维护性，以及更多的企业级特性。

嘿嘿，我真的找了好多教程，幻兽帕鲁服务器存档备份教程（Windows、Linux）：https://cloud.tencent.com/developer/article/2383775

group by 属于分组，会出现多行，这个需要根据分组后的数据 join的方式进行连接，不能放在现在的子查询里面

正常建立MySQL数据库并填写数据库配置信息即可

正确配置 wp-config.php 中的数据库连接，并检查数据库服务是否正常

利用docker吧。一键启动一键销毁

创建工单问问客服吧，真的出现这种情况，可就是事故了。 自己还是要做好每天的数据库备份才行。

这种情况下，建议先删除当前站点，重新建立站点的时候同时新建MySQL数据库

云函数支持web方式部署，你可以把你的phpadmin代码部署上去，开启云函数的外网访问，连接数据库只需要在代码里配置好数据库对应信息

可能的原因有： 1. 未正确设置数据库连接的错误处理。在连接数据库时，需要指定错误处理方式，例如设置连接的`autocommit`属性、`rollback`属性以及异常处理代码等。 2. 数据库连接被关闭。在插入数据期间，数据库连接可能被关闭，导致无法捕获插入数据时的异常，需要检查数据库连接是否被正确管理。 3. 数据库插入语句错误。可能是因为传入的数据格式不正确或者插入语句本身存在错误，导致无法捕获异常。 针对这些可能的原因，建议检查数据库连接的错误处理方式、连接状态以及插入语句的正确性，确保能够正确捕获插入数据时的异常。

程序长时间没有使用到数据库连接，它会自动断开链接，这是正常的。 在使用中遇到这类报错，重新创建连接就可以了。

授予"new_user"用户在"mydb"数据库上的所有权限： GRANT ALL PRIVILEGES ON mydb.* TO 'new_user'@'localhost'; FLUSH PRIVILEGES; 没有给new_user用户设置其他数据库的权限，它就无法操作其他的数据了。