相关疑难解决方法(0)

NOTE程序员.se和dba.se的受众不同，会有不同的观点，所以在这个例子中我认为复制什么是反对或支持将应用程序逻辑放在数据库层的论据是什么？在程序员.se上。

我已经找不到关于 dba 的讨论了，原帖已经说明了一切，所以：

大多数软件开发人员都希望将应用程序逻辑保留在应用程序层中，我们将它保留在这里可能感觉很自然。数据库开发人员似乎希望将应用程序逻辑放在数据库层，作为触发器和存储过程。

就我个人而言，我更愿意在应用层中保留尽可能多的内容，以便更容易调试并保持各层的职责分离。

您对此有何看法，在数据库层中应该或不应该实现什么？

注意，我不是该问题的 OP，但保留了原始措辞。

我们已经升级到 MySQL 5.6 并且开始看到 db server 的负载显着增加，最后发现 query_cache_type从 5.6 开始默认为 off start。

我们再次启用它并看到负载减少，为什么从 MySQL 5.6 开始默认禁用此值？我在启用它时看不到问题。

我目前正在研究一个 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 内存

这两个示例查询之间是否存在性能差异？

查询 1：

select count(*)
from   table1 a
join   table2 b
on     b.key_col=a.key_col
where  b.tag = 'Y'

查询 2；

select count(*)
from   table1 a
join   table2 b
on     b.key_col=a.key_col
   and b.tag = 'Y'

注意唯一的区别是补充条件的位置；第一个使用WHERE子句，第二个将条件添加到ON子句中。

当我在 Teradata 系统上运行这些查询时，解释计划是相同的，JOIN 步骤显示了每种情况下的附加条件。但是，在关于 MySQL 的这个 SO 问题上，其中一个答案表明首选第二种样式，因为WHERE在进行连接之后进行处理。

编码这样的查询时是否有一般规则要遵循？我猜它必须依赖于平台，因为它显然对我的数据库没有影响，但这也许只是 Teradata 的一个功能。而如果它是与平台相关的，我非常喜欢弄几个文件的参考资料; 我真的不知道该找什么。