这是我所做的，并将总执行时间减少了10倍。
我从原始查询的执行计划中意识到的是，它使用文件排序对所有结果进行排序并忽略了索引。那有点浪费。
我的测试数据库：500万条记录，20 GB大小。表结构与问题相同
而不是直接在第一个查询中直接获取blobCol，我首先获取每个页面开头的’name’值。无限期运行此查询，直到返回0个结果。每次将结果添加到列表中
SELECt nameFROM my_tablewhere id = <anyId> // I use the id column for partitioning so I need this hereorder by namelimit <pageSize * pageNumber>, 1
正弦页码以前未知，从值0开始，一直递增，直到查询返回null。您也可以执行选择计数（*），但它本身可能会花费很长时间，并且无助于优化任何内容。页数超过〜60后，每个查询大约需要2秒钟才能运行。
对我而言，页面大小为5000，因此我在位置0、5001、10001、15001等处获得了“名称”字符串列表。原来的页面数为1000，并在内存中存储1000个结果列表并不昂贵。
现在，遍历列表并运行此查询
SELECt blobColFROM my_tablewhere name >= <pageHeader>and name < <nextPageHeader>and city="<any string>"and id= 1
这将运行N次，其中N =先前获得的列表大小。由于“名称”是主键列，并且“城市”也已建立索引，因此EXPLAIN显示此计算是使用索引在内存中执行的。
现在，每个查询需要1秒才能运行，而不是原来的30-40。因此，结合每页2秒的预处理时间，每页总时间为3-4秒，而不是30-40。
如果有人有更好的解决方案，或者该解决方案存在明显错误，请告诉我
