我使用以下数据：
date latitude route name longitude
2009-04-11 00:50:31.640000 40.80708 White Loop 86 -77.85891
2009-04-11 00:50:27.718000 40.80708 White Loop 86 -77.85891
2009-04-11 00:50:01.562000 40.80708 White Loop 86 -77.85891
2009-04-11 00:49:48.765000 40.80708 White Loop 86 -77.85891
2009-04-11 00:49:34.796000 40.802338 White Loop 86 -77.85073
2009-04-11 00:49:22.468000 40.802338 White Loop 86 -77.85073
2009-04-11 00:48:35.671000 40.802338 White Loop 86 -77.85073
2009-04-11 00:48:29.125000 40.802338 White Loop 86 -77.85073
2009-04-11 00:47:19.906000 40.79889 White Loop 86 -77.85299
2009-04-11 00:47:03.609000 40.79889 White Loop 86 -77.85299
2009-04-11 00:46:54.437000 40.79889 White Loop 86 -77.85299
2009-04-11 00:46:52.687000 40.79889 White Loop 86 -77.85299
2009-04-11 00:46:51.125000 40.79889 White Loop 86 -77.85299
2009-04-11 00:46:48.578000 40.79889 White Loop 86 -77.85299
2009-04-11 00:46:41.406000 40.79889 White Loop 86 -77.85299
2009-04-11 00:50:31.687000 40.792194 White Loop 82 -77.863235
2009-04-11 00:50:27.781000 40.792194 White Loop 82 -77.863235
2009-04-11 00:50:01.640000 40.792194 White Loop 82 -77.863235
2009-04-11 00:49:48.812000 40.792194 White Loop 82 -77.863235
2009-04-11 00:49:34.843000 40.794914 White Loop 82 -77.866844
2009-04-11 00:49:22.531000 40.794914 White Loop 82 -77.866844
2009-04-11 00:48:35.718000 40.794914 White Loop 82 -77.866844
2009-04-11 00:48:29.156000 40.79738 White Loop 82 -77.86755
2009-04-11 00:47:19.984000 40.79738 White Loop 82 -77.86755
2009-04-11 00:47:03.656000 40.79738 White Loop 82 -77.86755
2009-04-11 00:46:54.484000 40.79738 White Loop 82 -77.86755
2009-04-11 00:46:52.734000 40.79738 White Loop 82 -77.86755
2009-04-11 00:46:51.156000 40.79738 White Loop 82 -77.86755
2009-04-11 00:46:48.640000 40.79738 White Loop 82 -77.86755
2009-04-11 00:46:41.453000 40.79738 White Loop 82 -77.86755
2009-04-11 00:50:31.656000 40.776066 White Loop 81 -77.88552
2009-04-11 00:50:27.750000 40.776066 White Loop 81 -77.88552
2009-04-11 00:50:01.593000 40.776066 White Loop 81 -77.88552
2009-04-11 00:49:48.796000 40.776066 White Loop 81 -77.88552
2009-04-11 00:49:34.812000 40.764687 White Loop 81 -77.88271
2009-04-11 00:49:22.515000 40.764687 White Loop 81 -77.88271
2009-04-11 00:48:35.703000 40.764687 White Loop 81 -77.88271
2009-04-11 00:48:29.140000 40.764687 White Loop 81 -77.88271
2009-04-11 00:47:19.937000 40.76335 White Loop 81 -77.876755
2009-04-11 00:47:03.640000 40.76335 White Loop 81 -77.876755
2009-04-11 00:46:54.468000 40.76335 White Loop 81 -77.876755
2009-04-11 00:46:52.718000 40.76335 White Loop 81 -77.876755
2009-04-11 00:46:51.156000 40.76335 White Loop 81 -77.876755
2009-04-11 00:46:48.609000 40.76335 White Loop 81 -77.876755
2009-04-11 00:46:41.437000 40.76335 White Loop 81 -77.876755
如何优化查询以仅获取每个“名称”的最新行？例如，我只想结束：
2009-04-11 00:50:31.640000 40.80708 White Loop 86 -77.85891
2009-04-11 00:50:31.687000 40.792194 White Loop 82 -77.863235
2009-04-11 00:50:31.656000 40.776066 White Loop 81 -77.88552
我希望所有结果的日期值都不超过1分钟。请记住，日期值是Python日期时间属性。
由于
答案 0 :(得分：1)
在SQL中，您可以做各种奇特的事情，但Google API相当有限。
鉴于您希望所有记录都不超过1分钟，我只需要向数据库询问不到1分钟的所有记录，然后让python整理结果并拒绝重复的行。
根据您在此处显示的数据，看起来您每分钟左右每个'名称'会得到几行，所以即使它不够优雅，这种方法应该足够了。
另一种方法是保留第二个表格，其中只包含每个“名称”的最新条目......并且不时地删除该表，以便删除一分钟以上的记录。
答案 1 :(得分：1)
我想我找到了一个不错的解决方案。问题出在我的模型中：
date = db.DateTimeProperty(auto_now_add=True)
这意味着对于该模型的每个实例，日期时间都会略有不同。这使得对我的数据进行分组非常困难。所以在我的cron函数中，我确保每个api请求都有完全相同的时间戳。
下一个更改是创建一个Current表。每次cron运行时，它都会删除Current表中的所有内容（只有一行），并添加一个新行。然后将此新行添加到Log表中，该表半永久性地存储结果。
答案 2 :(得分：1)
当然这会奏效：
query = db.GqlQuery("SELECT * FROM [table] ORDER BY date DESC LIMIT BY [num of rows]")
或者，您可以使用不等式，例如“date＆gt; 2009-04-11 00:50”，这将在此之后返回所有结果。