Question

我有这个简单的表

CREATE TABLE `user_did_something` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `something_id` int(11) NOT NULL,
  `user_id` int(11) NOT NULL,
  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `active` int(1) NOT NULL DEFAULT '1'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- Indexes for table `user_did something`
ALTER TABLE `user_did_something`
  ADD PRIMARY KEY (`id`);

当我尝试使用

插入时

INSERT INTO user_did_something (something_id, user_id) VALUES (1,11)

执行时间约为70毫秒。

在不同的机器上测试相同的结构，执行时间约为3ms。

其他信息：

版本10.0.28-MariaDB-0ubuntu0.16.04
表没有行
只有索引适用于主要的id列。

我不知道如何调试它。在线阅读一些内容，重新启动所有内容，结果仍然相同。

我正在寻找有关如何调试此类内容的指导，而无需在我的计算机上重新安装mysql服务器。

Answer 1

我正在寻找有关如何调试此类内容的指导，而无需在我的计算机上重新安装mysql服务器。

我会尽力回答你问题的这一部分。所以你想要了解一些流程的内幕，看看它在做什么。您不想重新编译它，重新安装它或重新启动它，并且您不希望受到它开箱即用的跟踪的限制。

这是使用DTrace的好机会！它可以让您了解您的流程正在做什么（以及much more）。

DTrace至少可在Solaris，Mac OS X *和FreeBSD以及I hear a port exists for Linux上使用。否则，您可以使用其他实用程序（BPF tracing got merged into Linux 4.9-rc1 recently）跟踪类似信息。

* Mac OS X用户需要explicitly permit DTrace to run，将其从系统完整性保护中排除

您可以在进入和退出函数时实时观看mysqld：

dtrace -p $(pgrep -x mysqld) -F -n 'pid$target:mysqld::entry{} pid$target:mysqld::return{}'

作为一些输出的例子...... InnoDB即使在空闲时也非常健谈：

2  -> sync_arr_wake_threads_if_sema_free    
6  -> os_event_reset                        
2    -> os_mutex_enter                      
6  <- os_event_reset                        
2    <- os_mutex_enter                      
6  -> pfs_mutex_exit_func                   
6  <- pfs_mutex_exit_func                   
2    -> os_mutex_exit                       
6  -> os_event_reset                        
2    <- os_mutex_exit                       
6  <- os_event_reset

您可以观看进入MySQL调度程序的查询！

dtrace -p $(pgrep -x mysqld) -F -n 'pid$target:mysqld:*dispatch_command*:entry{printf("Query: %s\n", copyinstr(arg2));}'

示例输出：

CPU FUNCTION                                 
0  -> dispatch_command(enum_server_command, THD*, char*, unsigned int) Query: SHOW VARIABLES LIKE 'pid_file'

我相信，在特定查询运行时，侦听发生的函数调用也属于DTrace的功能范围。例如：如果查询符合某些条件，则可以使mysqld:*dispatch_command*:entry初始化线程局部变量，并且仅在定义该变量时使pid$target:mysqld::entry|return打印。然后相应的mysqld:*dispatch_command*:exit或类似可以取消定义该变量。当然，如果您希望在单独的线程中进行工作，也可以使用全局变量。

很抱歉没有写上述具体的例子;我自己的MySQL被软管，我的DTrace书在办公室。

DTraceToolkit的作者Brendan Gregg提供了许多示例脚本，可用于监控您的错误进程，包括some one-liners用于监视进程是否遇到页面错误，读取有多大以及写道，它正在制作什么系统调用，等等。但如果你更全面地学习DTrace，你可以做得比单行更好。

我在这里介绍的脚本基于Ben Rockwood的文章Examining MySQL in real time using DTrace中提供的脚本。需要免费注册才能阅读。

我从Brendan Gregg的文章中了解了这个工具，并从Brendan的DTrace book中学到了更多关于DTrace的知识。如果你想看看兔子洞有多深，我强烈推荐这本书。

Answer 2

之前我遇到过同样的问题，并通过重启MySQL来解决问题。但正如你所说，你之前尝试过。我建议：

如果您使用的是Ubuntu，请检查防火墙。

检查缓存大小并检查它是否为ON：

SHOW VARIABLES LIKE have_query_cache;
SHOW VARIABLES LIKE query_cache_size;

检查正在运行的进程并可能放慢速度：

SHOW PROCESSLIST;

通过x $ statement_analysis检查您的查询费用更多：

SELECT * FROM sys.`x$statement_analysis`

检查全局状态。您可以在那里找到非常有用的信息，例如Threads_connected：

SHOW GLOBAL STATUS

Mysql性能不好

2 个答案: