【问题标题】:Prepared statement needs to be re-prepared after mysqltuner准备好的语句需要在mysqltuner之后重新准备
【发布时间】:2015-05-11 00:29:15
【问题描述】:

在运行 mysqltuner(麻烦版本 1.1 和 1.4)后,我的应用程序日志显示“需要重新准备准备好的语句”。一旦我运行“刷新表;”,错误就会消失。我在网上看过,大多数事情都提到了与这个错误有关的 mysqldump,但我没有运行 mysqldump。事实上,并没有真正做任何事情。因此,与此错误有关的几个问题:

  1. 一般来说,有任何与 mysqldump 无关的原因吗?
  2. 其他人在使用 mysqltuner 时遇到过这个问题吗?
  3. 这是否表明我需要研究更深层次的问题?

我的.conf:

[mysqld]
#
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
#  NOTE:  server did not like over 2GB
innodb_buffer_pool_size=1GB
innodb_log_buffer_size=9M
#
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
#
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
#  join_buffer_size = 128M
join_buffer_size = 2M
sort_buffer_size = 2M
read_rnd_buffer_size = 2M
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# Recommended in standard MySQL setup
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

lower_case_table_names=1

character-set-server=utf8
query_cache_size=100M
query_cache_type=1
slow_query_log=ON
query_cache_limit = 10M
table_open_cache=164000
open_files_limit=328000

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

如果您需要其他信息,请告诉我。

2015 年 3 月 10 日编辑: 我刚刚做了以下没有问题:

  1. 运行 mysqldump 将一个数据库(完整的,包含数据和函数)转储到“loadDB.sql”脚本以供以后使用。
  2. 添加了新数据库
  3. 使用“mysql
  4. 更新并添加行到我的新数据库 我对上述没有任何问题。

所以我只有在运行 mysqltuner 时才会遇到问题。我不知道的是如果

  1. mysqltuner 导致了这个问题,在这种情况下,我要么永远不运行 mysqltuner,要么立即运行“flush tables;”之后。
  2. 我的mysql配置有问题,后面会出现问题,需要解决。
  3. 或者还有其他一些我还没有考虑过的问题来源 第一步,也是这篇文章的原因,是确定 mysqltuner 是否会导致这个问题。

谢谢。

【问题讨论】:

  • 您是否在您的程序中使用任何准备好的语句?
  • 可能。它通过 ODBC 隐藏在 C 代码中。我担心的是在我运行 mysqltuner 之前一切似乎都很好。在那之后,事情会破裂并保持破裂,直到我运行“flush tables;”。我只是不明白 mysqltuner 怎么会影响这么大。
  • 好的,检查一个案例,我们在基于 ODBC 的代码中肯定有一个 prepare,但是涉及的 select 超级简单,并且限制为 1 行: SELECT 1 FROM mbo USE INDEX(mbo_mbodock) WHERE博斯特 = ? AND WHMSLayer_IS_LOC_ACCESSIBLE(?, ?, mbodoc) > 0 ORDER BY mbosts LIMIT 1.
  • 你能检查this question并尝试增加提到的变量的值吗?
  • 第一个回复:我的 table_open_cache 比那个帖子中的建议要大得多。但是我没有更改 table_definition_cache,所以我想我可以尝试一下。尽管如此,那个帖子说它有时仍然会发生。我没有看到任何证据表明他确实解决了这个问题。你知道不同吗?

标签: mysql mysqltuner


【解决方案1】:

mysqltuner 根本没有在代码中运行任何 FLUSH 命令。

我在最新的 1.5.1 版本中检查过。

【讨论】:

    猜你喜欢
    • 2018-09-26
    • 1970-01-01
    • 2015-08-27
    • 2018-12-14
    • 2021-06-24
    • 1970-01-01
    • 2021-12-16
    相关资源
    最近更新 更多