Create missing database indexes #596
Conversation
|
LGTM |
tboerger
added
the
lgtm/need 1
| UpdatedUnix int64 | ||
| HasRecentActivity bool `xorm:"-"` | ||
| HasUsed bool `xorm:"-"` | ||
| UpdatedUnix int64 `xorm:"INDEX"` |
| @@ -21,11 +21,11 @@ type AccessToken struct { | |||
| Sha1 string `xorm:"UNIQUE VARCHAR(40)"` | |||
|
|
|||
| Created time.Time `xorm:"-"` | |||
| CreatedUnix int64 | |||
| CreatedUnix int64 `xorm:"INDEX"` | |||
There was a problem hiding this comment.
I don't think we ever issue SQL queries that use the created_unix column of this table. Will adding an index here help us?
There was a problem hiding this comment.
It may not be useful in WHERE, but I think it is/will on ORDER BY.
There was a problem hiding this comment.
If my understanding of database indices is correct, a non-clustered index will not help ORDER BY clauses.
There was a problem hiding this comment.
:) It seems your discuss is not end after I merged.
There was a problem hiding this comment.
a non-clustered index will not help ORDER BY clauses
I thought it would.
@ethantkoenig Since I'm not a databases guru, if you still think we should not have these indexes, feel free to open another PR. I'd merge it. 😃
There was a problem hiding this comment.
@ethantkoenig A clustered index will actually rearrange the physical rows within the table. A non-clustered index will not affect the physical storage. ORDER BY clauses still work the same. Clustered indexes are useful where you often select a large number of rows from the index. The query optimiser will the perform a full table-scan as it's more efficient.
|
conflicted |
|
Conflicts resolved. |
|
LGTM |
tboerger
added
lgtm/done
Deprecates #297