[SERVER-35218] different result when query hint hint different indexes Created: 25/May/18 Updated: 27/Oct/23 Resolved: 31/May/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | 3.0.12, 3.2.16, 4.0.0-rc0 |
| Fix Version/s: | None |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | Jiangcheng Wu | Assignee: | William Byrne III |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Description |
query results with different results
index form will affect the data? Or were there right? I reproduces on v3.0, v3.2, v4.0-rc, may be affect more. reproduce process:
Any help will be appreciate. |
| Comments |
| Comment by William Byrne III [ 30/May/18 ] |
|
Hello Jiangcheng, This issue of the same query returning fewer documents depending upon which index is used is caused by starting MongoDB with the failIndexKeyTooLong set to false, which permits indexes to be created that do not link to all documents in a collection. MongoDB has always had a limit on the total size of an index entry of 1024 bytes. In releases up to version 2.4, if a document had key fields for an index that exceeded this limit, then that document was left out of the index. Version 2.6 implemented a stricter enforcement of the limit, and documents with overly long key field values would either fail to insert if the index already existed, or the createIndex command would fail if such a document was already in the collection. To assist customers upgrading from version 2.4 to 2.6 who had indexes and documents that violated the limit, the failIndexKeyTooLong parameter was added so they could disable the strict enforcement while they cleaned up their data or changed their indexing strategy. This parameter should not be enabled permanently, or for any purpose other that this upgrading use case. I recommend that you drop the "user.$id_1_word_1_image_1" index and consider replacing it with a hashed index on the image field field alone. Regards, William Byrne III |