相关疑难解决方法(0)

我一直在为不同的公司工作，我注意到他们中的一些人更喜欢拥有将所有“亲戚”加入表格的视图。但是在应用程序中，有时我们只需要使用 1 列。

那么只进行简单的选择，然后将它们“加入”到系统代码中会更快吗？

该系统可以是 php、java、asp 或任何连接到数据库的语言。

所以问题是，从服务器端（php、java、asp、ruby、python...）到数据库并运行一个查询来获取我们需要的一切或从服务器端到数据库并运行哪个更快？一次只从一个表中获取列的查询？

我有一个很烦人的问题。我想使用 INNODB 作为我的主要数据库引擎并放弃 MyISAM，因为我需要前者来使用 galera-cluster 进行冗余。

我将newbb_post表复制（描述如下）到一个名为的新表newbb_innopost并将其更改为 InnoDB。每个表当前都保存5,390,146条目。

在新启动的数据库上运行这些选择（因此此时不涉及缓存！）数据库产生以下结果（省略完整的输出，请注意我什至不要求数据库对结果进行排序）：

SELECT post.postid, post.attach FROM newbb_post AS post WHERE post.threadid = 51506;

.
.
| 5401593 | 0 |
| 5401634 | 0 |
+---------+--------+
62510 行（0.13 秒）

SELECT post.postid, post.attach FROM newbb_innopost AS post WHERE post.threadid = 51506;
.
.
| 5397410 | 0 |
| 5397883 | 0 |
+---------+--------+
62510 行（1 分 22.19 秒）

0.13 秒到 86.19 秒 (!)

我想知道为什么会这样。我确实在 Stackexchange 上阅读了一些涉及 InnoDB …

我目前正在研究一个 MySQL 数据库，我们看到查询缓存中有大量无效，主要是因为在许多表上执行了大量的 INSERT、DELETE 和 UPDATE 语句。

我要确定的是，允许将查询缓存用于针对这些表运行的 SELECT 语句是否有任何好处。由于它们很快就失效了，在我看来，最好的办法是在这些表的 SELECT 语句上使用 SQL_NO_CACHE。

频繁失效的开销值得吗？

编辑：应以下用户@RolandoMySQLDBA 的要求，这里是有关 MyISAM 和 INNODB 的信息。

数据库

• 数据大小：177.414 GB
• 索引大小：114.792 GB
• 表大小：292.205 GB

我的ISAM

• 数据大小：379.762 GB
• 索引大小：80.681 GB
• 表大小：460.443 GB

附加信息：

• 版本：5.0.85
• 查询缓存限制：1048576
• query_cache_min_res_unit：4096
• 查询缓存大小：104857600
• query_cache_type：开启
• query_cache_wlock_invalidate：关闭
• innodb_buffer_pool_size: 8841592832
• 24GB 内存

为什么 MySQL 在 8.0 版本之后去掉了查询缓存功能？

我们有一个非常强大的服务器：HP ProLiant DL360p Gen8, 2xIntel Xeon E5-2630 2.30GHz, 128GB of RAM.

整个数据集应该适合内存：

mysql> SELECT FLOOR(SUM(DATA_LENGTH+INDEX_LENGTH)/POWER(1024,2)) 'Total Size (MB)', FLOOR(SUM(DATA_LENGTH)/POWER(1024,2)) 'Data Size (Data_length in MB)', FLOOR(SUM(INDEX_LENGTH)/POWER(1024,2)) 'Index Size (Index_length in MB)' FROM information_schema.TABLES;
+-----------------+-------------------------------+---------------------------------+
| Total Size (MB) | Data Size (Data_length in MB) | Index Size (Index_length in MB) |
+-----------------+-------------------------------+---------------------------------+
|          110559 |                         62464 |                           48095 |
+-----------------+-------------------------------+---------------------------------+
1 row in set (1.64 sec)

-innodb_buffer_pool_size是 100GB

mysql> SELECT (@@innodb_buffer_pool_size / POWER(1024,3)) AS "innodb_buffer_pool_size in GB"; …

我想请您澄清 mysqltuner 关于 MariaDB 数据库的报告。mysqltuner 是用 --nogood 标志调用的！

 >>  MySQLTuner 1.7.1 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering

[--] Skipped version check for MySQLTuner script
[!!] Currently running unsupported MySQL version 10.0.29-MariaDB-0ubuntu0.16.04.1

-------- Log file Recommendations ------------------------------------------------------------------
[--] Log file: (0B)
[!!] Log file  doesn't exist
[!!] Log file  isn't readable.

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +ARCHIVE +Aria +BLACKHOLE +CSV +FEDERATED +InnoDB …

我们每天都在经历大量的查询缓存修剪，目前为 80851746。即使在 50 多个并发连接的合理负载下，MySQL 也确实很挣扎。

主机是具有配置为 RAID 5、24 核和 128GB RAM 的 SSD 的物理服务器。它是一个专用的 MySQL 5.6 服务器，可供各种 PHP 客户端访问。

实例由3个数据库组成，总大小为1TB，所有表都是InnoDB并经过压缩。

我在下面包含了尽可能多的信息，任何建议将不胜感激。如果需要，我可以提供更多信息。谢谢。

操作系统信息

# lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:    14.04
Codename:   trusty

# uname -a
Linux xxxxxxxxxx 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

内存信息

# free -m
             total       used       free     shared    buffers     cached
Mem:        128915     128335        580          0        396      78764
-/+ buffers/cache:      49174      79740
Swap:        30517        192      30325

CPU信息 …