1

アクティビティ ログを格納するテーブル (InnoDB) があります。各行には、ユーザー ID、アクティビティ ID、および位置データがあります。ユーザー ID とアクティビティ ID の列は、一意ではありませんが、インデックスが作成されます。

select *返されたデータを照会すると、正常に見えます-

select * from table

ユーザー ID またはアクティビティ ID を別の列 (これら 2 つを一緒にしても) でクエリすると、データは正常に見えます。

select user_id, city from table

whereステートメントを使用してユーザーIDまたはアクティビティIDのみを照会すると、データは正常に見えます。

select user_id from table where city = 'boulder'

この問題は、ユーザー ID またはアクティビティ ID のみをクエリするか、部分文字列クエリを使用して同じ列の where ステートメントを使用して 1 つだけをクエリすると発生します。

select user_id from table

また

select user_id from table where substring(user_id, 1,5) = '12345'

返されるデータはフィールド内のデータではなく、インデックスの場所 (または類似のもの) のように見えます。インデックスを削除したところ、問題は修正されましたが、インデックスを追加し直すとすぐに再発しました。

インデックスなしの例 -

user_id   
-------
123456789
231234567
234567543

インデックス付きの例 -

user_id
-------
081357652234
100000000000000
1000000000011

サーバーを再起動してから、API からデータをリロードしようとしましたが、何も役に立ちませんでした。この問題を経験することなく、同じデータベース内の他のテーブルでこれをテストしました。

これはバグですか、それとも設定の間違いですか?

4

1 に答える 1

2

私は...するだろう：

  • テーブルの名前を変更して（user_activityに更新したようです）、テーブル名がSQLのキーワードでもあるために発生する可能性のあるバグを回避します
  • データベースのバックアップを作成します
  • check table user_activityエラーに対してa を実行します
  • user_id が int 型であることを確認してください

UPDATE : user_id が varchar であるというコメントの 1 つからわかるように、クエリによって返される 2 番目と 3 番目の ID がバイナリのように見えるため、バグに遭遇した可能性があります。InnoDB を使用しているため、実行することはできませんが、これREPAIRを見ることはできます。データベースをダンプしてリロードして、問題が状況に応じて発生するのか、それとも常に発生しているのかを確認することもお勧めします。

于 2013-08-15T15:57:44.663 に答える