Question

这是MySQL的正确有序数组：

[
  [1330210800000, 1],
  [1330297200000, 6],
  [1330383600000, 10], 
  [1330470000000, 2],
  [1330556400000, 5],
  [1330815600000, 9],
  [1331593200000, 2], 
  [1331852400000, 4],
  [1331938800000, 8],
  [1332111600000, 8],
  [1332198000000, 4], 
  [1332284400000, 8],
  [1332370800000, 3], 
  [1332630000000, 2] 
]

但是对于PostgreSQL，数组是：

[
  [1330588800000, 5], 
  [1332399600000, 3], 
  [1330848000000, 9], 
  [1330416000000, 10], 
  [1331622000000, 2], 
  [1330329600000, 6], 
  [1330502400000, 2], 
  [1332140400000, 8], 
  [1332313200000, 8], 
  [1330243200000, 1], 
  [1332226800000, 4], 
  [1331967600000, 8], 
  [1332658800000, 2], 
  [1331881200000, 4] 
]

postgreSQL是错误的订单，日期不同，还有kliks的数量：

这是我控制器中的查询：

@kliks = Klik.count( :group => "DATE( created_at )" )
         .map{|k, v| [(Time.parse(k).to_i * 1000), v] }

Answer 1

您没有在查询中指定任何特定顺序，因此数据库可以按任何顺序自由返回结果。显然，MySQL将结果排序为其GROUP BY的副作用，但PostgreSQL不一定会这样做。因此，您的第一个“错误”只是您的错误假设。如果您希望数据库进行排序，那么您需要以下内容：

Klik.count(:group => 'date(created_at)', :order => :date_created_at)

如果你抛出* 1000并对整数时间戳进行排序：

1330210800, 1,  MySQL
1330243200, 1,  PostgreSQL

1330297200, 6,  MySQL
1330329600, 6,  PostgreSQL

1330383600, 10, MySQL
1330416000, 10, PostreSQL

...

你会发现他们确实排队很好，每个MySQL / PostgreSQL对的整数时间戳相差32400s（AKA 9小时）或28800s（AKA 8小时或9小时DST调整）。大概你在一个转换中包含一个时区（带有DST），而另一个留在UTC中。

Answer 2

你真的错过了订单条款。默认情况下，数据库服务器以“随机”顺序返回组。 规则是：当您需要修改订单时，请始终使用ORDER BY（在rails中：订单）。

PostgreSQL组命令数组完全错误

2 个答案: