我正在处理大量数据，并且在 phpMyAdmin 中检查我的数据时开始出现奇怪的行为.当计数很高时，行计数显示 ~ 前缀，据说是计数的估计值.我也会得到例如;711页数据(x 30行)，选择第711页(最后一页)，然后它会提供更多的800页，选择时等于none.
I am working with large amounts of data and starting to get odd behavior when checking my data in phpMyAdmin. Row counts display ~ prefixes when count is high, supposedly estimates of the count. I will also get for example; 711 pages of data (x 30 rows), select the 711th page (last one) and then it will offer up more pages in the 800's, that are equal to none when selected.
这篇文章在这里描述了这个问题，但是它不提供解决方案或潜在的不稳定性.我已经开始完善我的数据类型、键和插入过程，但在理解如何解决这个问题或是否有任何看不见的数据弃用方面运气不佳.插入和更新来自本地 PHP 和服务器外 Python，如果这有什么不同的话.
This post describes the issue here but it does not offer a solution or potential instabilities. I have taken on perfecting my data types, keys and insertion process with little luck on understanding how to fix this or if there is any unseen deprecation of my data. The inserts and updates come from local PHP and off-server Python if that makes any difference.
如果您使用 InnoDB 表，则近似计数是其事物"之一，如此处.它与 phpMyAdmin 没有任何关系.phpMyAdmin 只是数据库的前端，它依赖于数据库提供的数据；如果数据库只能快速提供近似计数，那就够了.
If you're using InnoDB tables, approximate counts are one of its "things", as described here. It has nothing really to do with phpMyAdmin. phpMyAdmin is just a frontend for the database and it relies on the data given by the database; if the database can only supply approximate counts quickly, then that's it.
而且由于 phpMyAdmin 只是一个简化与数据库的基本交互的工具，我看不出有什么大问题.它不应该是您开始浏览 800 页数据的主要工具.但是，如果您遵循 phpMyAdmin 提供的提示，您最终会得到一个解决方案这里.
And since phpMyAdmin is only a tool to simplify basic interactions with the database, I don't see the big issue. It shouldn't be your primary tool to browse through 800 pages of data to begin with. But, if you'd follow the hints provided by phpMyAdmin, you'd end up with a solution here.
这篇关于什么是 phpMyAdmin 的 20,000 行限制的修复或迁移，是否真的不稳定?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！