MYSQL 临时表 - 如何查看活动表
我们公司有一个简单的“类似crm”的软件。有一些复杂的查询需要一些时间,日常使用的查询......所以我正在测试一些修改以使用临时表来替换我们需要的所有复杂联接和子查询。
到目前为止进展顺利,速度达到了 90% 以上。
由于它是一个网络应用程序(codeigniter + mysql),我计划将其放入“生产测试”环境中,以便 50% 的用户可以帮助我测试它。我想监视活动的表,如果可能的话,监视每个连接。
我的问题是 - 有什么方法可以查看 mysql 实例中活动的所有临时表吗?也许查看其数据?
我读过一些有关插件或类似内容的内容,但这篇文章太混乱了,我无法理解。
非常感谢,也很抱歉我的英语——不是我的母语。
We have a simple "crm-like" software in our company. There are some complex queries that were taking some time, daily-use queries... so i am testing some modifications to use Temporary Tables to replace all the complex joins and subqueries we need.
So far going really well, got a 90%+ speed.
Since its a web app (codeigniter + mysql), i plan to put it in a "production-test" enviroment so 50% of the users can help me test it. I would like to monitor the tables that are active, and if possible for each connection.
My question is - Is there any way i can view all the TEMPORARY TABLES that are active in the mysql instance? Maybe view its data?
I read something about a PLUGIN or something like, but the article was far to messy and i coudnt understand.
Thanks alot and sorry for my english - not my native lang.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
temp table = 临时表,它在查询后立即删除
,没有直接的解决方案,除了记录所有查询并逐一执行以检查哪个查询需要 tmp_table
等系统变量,例如 Created_tmp_tables 可能会给出一些想法
temp table = temporary, it deleted right after the query
there is no direct solution, except logging all the queries and execute one-by-one to exam which query require tmp_table
the system variables like
Created_tmp_tables
might give some ideas临时表的问题之一实际上是跟踪使用情况,然后是创建、索引和删除它们的开销 - 特别是对于临时表的生命周期通常与 HTTP 请求的生命周期一样长的 Web 应用程序。
在预编译结果(即物化视图)有用的情况下,我设置了一个常规表,添加引用 MySQL 连接 id / Web 会话 id / 源查询 + 根据 TTL 生成的时间的字段数据以及是否会共享。
除了详细跟踪表的使用情况之外,它还使解决查询调整变得更加容易,当然,模式也得到了更好的记录。
One of the problems of temporary tables is actually tracking the usage, then there's the overhead of creating, indexing and deleting them - particularly with a web application where the lifetime of the temporary table is usually as long as the lifetime of the HTTP request.
Where pre-compiled results (i.e. materialized views) will be of benefit, I set up a conventional table, adding field(s) which reference the MySQL connection id / the web session id / the source query + time generated depending on the TTL for the data and whether it will be shared or not.
In addition to getting detailled tracking of the usage of the table, it makes it much easier to address query tuning and of course, the schema is better documented.
MySQL INNODB 从 v5.7 开始提供有关来自
INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INF
的临时表的一些信息,但它仅显示服务信息,而不显示有关表结构或名称的详细信息MySQL INNODB from v5.7 provides some information about temporary tables from
INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INF
but it shows only service information without details about table structure or name我认为这在视图临时表中没有意义,因为它们在连接期间存在,并在关闭连接后消失。但关于临时表有一个重要的事实。因此,如果您在脚本中使用持久连接,临时表将在此连接的生命周期内一直存在,并且使用此连接的客户端将可以访问相同的临时表。同样在这种情况下临时表也会消耗系统资源。为了避免这种情况,您应该在运行使用此临时表的必要查询后手动删除临时表。
I believe that it doesn't make sense in view temp tables because of they live during connection and die after closing connections. But there is one important fact about temporary table. So if you use persistent connection in your scripts temporary table will live during life of this connection and clients which use this one will get access to the same temporary tables. Also in this case temp table will consume system resources. For avoiding it you should remove temp tables manually after run query necessary query which is used this temp table.
当您的数据集变得更大时,临时表将无法为您提供帮助。最后,他们如何提供帮助?计算结果后必须将数据复制到这些表中,为什么不使用 memcached 缓存结果呢?
此外,我还看到过一些数据库有些大(数十 GB),并且在单台机器上运行,并且查询运行得很快。存在一个问题:您是否正确配置了数据库服务器(软件和硬件)。您可能会遇到暂时的加速,但不能保证它会永久有效。我会优化运行应用程序所需的应用程序、查询、软件和硬件,然后使用 memcache 缓存结果,除非您需要查询结果的最新热副本。
When your data-set grows larger, temporary tables won't help you. In the end, how do they help? The data has to be copied into those tables after you calculate the result, why not cache the results with memcached?
Also, I've seen databases that are somewhat large (tens of gigabytes) and are running off of a single machine and queries were running quickly. There's a question whether you configured your database server properly (software and hardware). You might be experiencing temporary speedup, but there's no guarantee it's going to work permanently. I'd optimize the application, queries, software and hardware required to run the app and then I'd cache the results with memcache unless you need the latest hotcopy of the query result.