打开\config.inc.php文件并附加以下两行：

$cfg['MaxExactCount'] = 0;
$cfg['MaxExactCountViews'] = 0;

当然，如果数据库中没有任何视图，则可以跳过第二行。

这是因为你有很多行的inoDB表。InnoDB不存储表中的行数，但MyISAM存储。所以对于每个InnoDB表，PHPMyAdmin调用SELECT count(*) FROM查询，如果行数非常高，则该查询非常慢。要解决此问题，你应该编辑config.inc.php文件并设置$cfg['MaxExactCount']。这将为具有较少MaxExactCount行的表调用count(*) sql。

$cfg['MaxExactCount'] = 20000;

含义形式phpmyadmin手册
对于InnoDB表，确定phpMyAdmin应该使用SELECT COUNT获取多大的表的精确行数。如果SHOW TABLE STATUS返回的近似行数小于这个值，则使用SELECT COUNT，否则使用近似行数。

phpMyAdmin在本地服务器上运行缓慢的另一个原因是它明显忽略了hosts文件.尝试将config.inc.php中出现的“localhost”更改为“127.0.0.1“.这为我在Windows计算机上创建了一个很大的加速.

如果您有多个包含大量（〉10^5）记录的视图，即使MaxExactCountViews和MaxExactCount都设置为100，它也会运行得非常慢。
查找
'静态公共函数countRecords'
在
libraries\Table.class.php
中，将以下代码放在此方法的开头：

if ($is_view == true && isset($GLOBALS['cfg']['MaxExactCountViews'])) {
    /* dirty hack to avoid performance issue with views when ['cfg']['MaxExactCount'] and ['cfg']['MaxExactCountViews'] does not help it */
    $tmp_tables = PMA_DBI_get_tables_full($db, $table);
    PMA_Table::$cache[$db][$table] = $tmp_tables[$table];
    PMA_Table::$cache[$db][$table]['ExactRows'] = $GLOBALS['cfg']['MaxExactCountViews'];
    return (int) $GLOBALS['cfg']['MaxExactCountViews']; 
}

Set $GLOBALS['cfg']['MaxExactCountViews']值在配置之后。phpMyAdmin现在将始终显示此值的所有视图。它也将工作得更快：-）

我解决这个问题的方法是将SHOW TABLE STATUS FROM <DATABASE>的输出缓存到一个名为 f.i.showtablecache的表中，比如说每隔2分钟缓存一次，您可以使用数据库的一些cron脚本来实现这一点。
然后，您可以编辑文件/usr/share/phpmyadmin/libraries/database_interface.lib.php，并在新的缓存表中用SELECT ... FROM showtablecache WHERE ...替换慢的SHOW TABLE STATUS FROM ...。
您也可以不使用phpmyadmin源代码，而在它们之间放置一个mysql-proxy示例，该示例为您执行查询重写，然后您所要做的就是更改config-db.php中的$dbport变量：）
如果您在使用phpmyadmin以外的非开源工具时遇到这个问题，使用mysql-proxy将特别有用。就像一些本机的、可能是专有的工作台应用程序一样。（Upscene的Database workbench做了类似的事情（如果我没记错的话））
cron脚本中的查询：

START TRANSACTION;

DELETE FROM showtablecache WHERE database_ = '<DATABASE>';

INSERT INTO showtablecache
SELECT 
    '<DATABASE>'
    , TABLE_NAME
    , ENGINE
    , VERSION
    , ROW_FORMAT
    , TABLE_ROWS
    , AVG_ROW_LENGTH
    , DATA_LENGTH
    , MAX_DATA_LENGTH
    , INDEX_LENGTH
    , DATA_FREE
    , AUTO_INCREMENT
    , CREATE_TIME
    , UPDATE_TIME
    , CHECK_TIME
    , TABLE_COLLATION
    , CHECKSUM
    , CREATE_OPTIONS
    , TABLE_COMMENT
FROM
    INFORMATION_SCHEMA.TABLES
WHERE
    table_schema = '<DATABASE>';

COMMIT;

因此，您可以使用以下命令代替SHOW TABLE STATUS FROM <DATABASE>：

SELECT
    Name_ AS `Name`,
    Engine_ AS `Engine`,
    Version,
    Row_format_ AS `Row_format`,
    Rows_ AS `Rows`,
    Avg_row_length,
    Data_length,
    Max_data_length,
    Index_length,
    Data_free,
    Auto_increment_ AS `Auto_increment`,
    Create_time,
    Update_time,
    Check_time,
    Collation_ AS `Collation`,
    Checksum,
    Comment_ AS `Comment`,
    Create_options
FROM
    showtablecache
WHERE
    Database_ = <DATABASE>;

有关此修复的详细信息，请单击此处：http://blog.cppse.nl/fix-slow-phpmyadmin

我最初使用@“Andrew Kondratev”answer，没有“if view”条件，然后开始仔细研究该方法的其余部分，意识到这几乎就是$force_exact为false时运行的代码。我有一个新的更简单的黑客，不会破坏太多，也适用于 tables。
就像安德鲁的黑客攻击一样：

• 查找安装所在的位置，例如rpm -ql phpMyAdmin | grep Table.class.php（或本地操作系统等效项）。
• 编辑：./libraries/Table.class.php（在我的示例中为/usr/share/phpMyAdmin/libraries/Table.class.php
• 查找static public function countRecords（在我的示例中为第563行）
• 在该函数的顶部（{之后）插入以下内容：

/* Tommy's Hack from http://goo.gl/HMTnLc */
        $force_exact = false;
        /* End Tommy's Hack - USE AT YOUR OWN RISK! */

• 在我的例子中，“默认值”已经有了以下内容：

config.default.php: * @global integer $cfg['MaxExactCount']
config.default.php:$cfg['MaxExactCount'] = 0;
config.default.php: * @global integer $cfg['MaxExactCountViews']
config.default.php:$cfg['MaxExactCountViews'] = 0;

• 但是，您可以随时将其添加到您的config.inc.php中：

$cfg['MaxExactCountViews'] = 0;//disable trying to count the number of rows in any view
$cfg['MaxExactCount'] = 0;//disable correcting the InnoDB estimates

型
我相信这个问题在tbl_info.inc.php中已经解决了，它在显示表时将$force_exact设置为true。IMO，只有当你试图查看最后一页时，这个数字才需要是“exact”的，即使这样也可能不是。

对我来说，问题是xdebug profiler对所有站点都是打开的，当在phpmyadmin中加载表列表时，它会写超过40 MB的日志（关闭它会将加载从15秒加速到2-3秒）。
下面是我的新xdebug设置，我不知道是哪一个成功了：

xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=1 # this still allows manual logs
xdebug.remote_autostart=0
xdebug.remote_enable=0

我针对查询information_schema.tables的一般情况发布了一个修复程序
对information_schema.表的查询速度慢

我今天遇到了这个问题，总共有20个表DB，120GB。
每当我在PhpMyAdmin中单击数据库名称时，它总是要列出表，并且通常会返回Web服务器超时。
这发生后，我重命名数据库多次和导入和导出大量的数据.
感觉它尝试重新计算表统计信息，但失败或超时。

适合我的解决方案：

• 我逐个单击了PhpMyAdmin左列上的表名
• 输入每个表后，我单击顶部的**结构选项卡
• 滚动到结构页面底部，Space usage下显示表存储使用不准确，如60KB;
• 右键单击并刷新浏览器中的结构页面
• 好像是重新计算表统计，现在Space usage好像是准确的，比如2GB;
• 在对所有表执行此操作之后，它可以更快地列出表。