StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
19287268
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-10-10T04:47:33.240
FavoriteCount
0
LastActivityDate
2013-10-10T05:08:41.320
LastEditDate
2013-10-10T05:08:41.320
LastEditorUserId
2067753
OwnerUserId
2067753
ParentId
18590222
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
Have you studied the execution plan? I suspect the performance issue is deeper down than the final use of exists and it would help if the full query was available - or at least a full representation of its structure. In a comment you indicate this more elaborate structure: <pre><code>SELECT 1 FROM table_A AS a LEFT JOIN ( -- << why a left join, is it achieving anything? SELECT * -- << not literally select * I hope FROM table_B AS b JOIN table_C AS c ON b.thing = c.thing WHERE B.ColumnA IN ( -- << avoid this type of IN() SELECT -- >> if this result is big columnX FROM table_D AS d ) ) AS x ON a.thing = x.thing ; </code></pre> At the outer query you are (or at least indicating) only doing 'select 1' so no extraneous fields need be selected in nested subqueries. You indicate the use of a left join, but so little is known about the details that I can't tell if it's needed or not. Possibly the most obvious place to look for improvement would be use of IN( subquery here ) if that subquery is producing a substantial number of rows performance will degrade. Either a join or the use of EXISTS is likely be a better choice for this. EDIT: with respect to getting an execution plan, consider running each subquery independently starting with the inner most nesting: <pre><code> SELECT -- >> if this result is big columnX FROM table_D AS d </code></pre> Is it using indexes, how many rows are returned (perhaps just do a count(*) for that) Work up from there to the next subquery, and consider alternatives. e.g. this might work: <pre><code> SELECT thing -- << only that which is needed FROM table_B AS b JOIN table_C AS c ON b.thing = c.thing JOIN ( SELECT distinct -- >> not a fan of distinct but might help here columnX FROM table_D ) AS D ON B.ColumnA = D.columnX </code></pre> What does the execution plan of this piece tell you? Working up like this should aid the overall optimization. 
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POIf exists statement in SQL timing out
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USUsed_By_Already
UserOwnerUserId
1. USUsed_By_Already
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POIf exists statement in SQL timing out
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
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.