StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
17372873
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-06-28T20:11:15.790
FavoriteCount
0
LastActivityDate
2013-06-28T20:11:15.790
LastEditDate
LastEditorUserId
0
OwnerUserId
20860
ParentId
17372357
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
Even if the indexed column doesn't have many distinct values, an index is beneficial in cases when the value you're searching for is uncommon. In other words, the index helps when the search is more selective, and matches a small percentage of rows. So in this case, the decision about creating an index is based on what percentage of rows match your conditions <code>scrape_status=1</code> and <code>parse_status=0</code>. For example, suppose <code>scrape_status=1</code> matches 2% of rows, and <code>parse_status=0</code> matches 1% of rows, I'd want to use <code>parse_status</code> as the leading column for the index. If that's the case, but nearly all rows with <code>parse_status=0</code> also have <code>scrape_status=1</code>, then there may be little additional benefit to making a compound index. Whereas if <code>scrape_status=1</code> is effective at further restricting the matching rows, then you'd definitely want it to be built into the index. MySQL also has optimizations for LIMIT. see <a href="http://dev.mysql.com/doc/refman/5.6/en/limit-optimization.html" rel="nofollow">http://dev.mysql.com/doc/refman/5.6/en/limit-optimization.html</a> It tries to bail out of the query as soon as it finds the desired number of matching rows. MySQL 5.6 has added some new optimizations in this area. MYSQL does not calculate the select-list expressions for rows that don't match conditions in the WHERE clause. However, MySQL does have to read rows of data from disk to evaluate them against the conditions in the WHERE clause. This I/O is the source of a lot of performance cost, and it's the reason that narrowing down the search with indexes is so important. And if your <code>source_html</code> column is a TEXT column containing long strings, it's likely that this adds further overhead to the I/O, because MySQL will have to read additional pages of data from disk (see <a href="http://www.mysqlperformanceblog.com/2010/02/09/blob-storage-in-innodb/" rel="nofollow">Blob Storage in Innodb</a> for more details). 
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POSpeed of MySQL SELECT (are indexes worth it on columns with little variation)?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USBill Karwin
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.