针对约 225 万行的单表选择查询的优化技术？

我有一个在 InnoDB 引擎上运行的 MySQL 表，名为squares大约有 2,250,000 行，表结构如下：

`squares` (
   `square_id` int(7) unsigned NOT NULL,
   `ref_coord_lat` double(8,6) NOT NULL,
   `ref_coord_long` double(9,6) NOT NULL,
   PRIMARY KEY (`square_id`),
   KEY `ref_coord_lat` (`ref_coord_lat`),
   KEY `ref_coord_long` (`ref_coord_long`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

第一栏square_id保存一个从 0 - 2.25M 的简单递增值，而ref_coord_lat & ref_coord_long分别保存一个点的一组以十进制表示的纬度和经度坐标。

这是一个只读表。不会添加任何其他行，并且需要对其运行的唯一查询如下：

SELECT * FROM `squares` WHERE 
  `ref_coord_lat` BETWEEN :southLat AND :northLat AND 
  `ref_coord_long` BETWEEN :westLong AND :eastLong

...其中冒号后面的值是 PHP PDO 占位符。本质上，此查询的目标是获取表中当前位于 Google 地图窗口视口中的所有坐标点，该窗口以查询中的 4 个坐标为界。

我限制了使用 Google Maps API 运行此查询的缩放级别，以便可以获取的最大行数为~5600。随着缩放级别的增加，最终的提取总数显着减少。

直接在 PHPMyAdmin 中运行这样的示例查询需要 1.40-1.45 秒。这太长了。我已经在运行标准索引ref_coord_lat and ref_coord_long这将查询时间从约 5 秒缩短，但这对于最终用户期望及时响应的地图来说仍然太大。

我的问题很简单：如何进一步优化此表/查询以提高获取结果的速度？

创建复合索引(lat, long)应该有很大帮助。

然而，正确的解决方案是看看MySQL 空间扩展 http://dev.mysql.com/doc/refman/5.5/en/spatial-extensions.html。空间支持是专门为处理二维数据和针对此类数据的查询而创建的。如果您创建适当的空间索引，您的典型查询性能应该很容易超过复合索引的性能(lat, long).