sql-execution-plan

问题 I'm calling extremely simple query from Python program using pymsqsql library. with self.conn.cursor() as cursor: cursor.execute('select extra_id from mytable where id = %d', id) extra_id = cursor.fetchone()[0] Note that parameter binding is used as described in pymssql documentation. One of the main goals of parameter binding is providing ability for DBMS engine to cache the query plan. I connected to MS SQL with Profiler and checked what queries are actually executed. It turned out that

问题 How do conditional statements (like IF ... ELSE ) affect the query execution plan in SQL Server (2005 and above)? Can conditional statements cause poor execution plans, and are there any form of conditionals you need to be wary of when considering performance? ** Edited to add ** : I'm specifically referring to the cached query execution plan. For instance, when caching the query execution plan in the instance below, are two execution plans cached for each of the outcomes of the conditional?

问题 I'm using SQL Server 2008. I have a table with over 3 million records, which is related to another table with a million records. I have spent a few days experimenting with different ways of querying these tables. I have it down to two radically different queries, both of which take 6s to execute on my laptop. The first query uses a brute force method of evaluating possibly likely matches, and removes incorrect matches via aggregate summation calculations. The second gets all possibly likely

问题 I've got a very simple table which stores Titles for people ("Mr", "Mrs", etc). Here's a brief version of what I'm doing (using a temporary table in this example, but the results are the same): create table #titles ( t_id tinyint not null identity(1, 1), title varchar(20) not null, constraint pk_titles primary key clustered (t_id), constraint ux_titles unique nonclustered (title) ) go insert #titles values ('Mr') insert #titles values ('Mrs') insert #titles values ('Miss') select * from

问题 Just requesting some clarification on the difference between the 2. From what I understand, EXPLAIN PLAN gives you the theoretical execution plan while DBMS_XPLAN.DISPLAY_CURSOR gives you the actual execution plan with execution statistics for the statement. EXPLAIN PLAN stores this data in a PLAN_TABLE while DBMS_XPLAN uses the V$SQL_PLAN, V$SQL_PLAN_STATISTICS and V$SQL_PLAN_STATISTICS_ALL views for its information. However, for DISPLAY_CURSOR to collect the actual runtime statistics for

问题 I'm looking for an application to display what a linq expression would do, in particular regarding the usage of multiple access to the same list in a query. Better yet, the tool would tell if the linq query is good. 回答1: I used the expression tree visualizer in the past to at least help decode what is inside of an expression tree. It aids in figureing out the parts of the tree and how gives each part is related. 回答2: Well, to begin with, I could easily foresee a tool that would pick a query

问题 I have a relative simple query SELECT , db1.something , COALESCE(db2.something_else, 'NA') AS something2 FROM dwh.db_1 AS db1 LEFT JOIN dwh.db_2 AS db2 ON db1.some_id = db2 = some_id EXPLAIN gives an estimated time of something more than 15 seconds. On the other hand, explain on the following, where we basically replaced the alias with the table name: SELECT , db1.something , COALESCE(db_2.something_else, 'NA') AS something2 FROM dwh.db_1 AS db1 LEFT JOIN dwh.db_2 AS db2 ON db1.some_id = db2

问题 I get two answers: 1, 2. But I still do not know which is efficient. Here is explain of both: explain for my query: Hash Anti Join (cost=136.09..138.49 rows=1 width=556) Hash Cond: (t1.id = t2.parent_id) CTE tree -> Recursive Union (cost=0.14..132.81 rows=101 width=556) -> Index Scan using resource_type_idx_parent_resource_type_id on resource_type (cost=0 Index Cond: (parent_resource_type_id IS NULL) -> Hash Join (cost=0.33..12.26 rows=10 width=556) Hash Cond: (rt.parent_resource_type_id =

问题 This question comes as a follow up to and a result of SQL function very slow compared to query without function wrapper. I should note that I don't consider this a duplicate, since that question was asking for a solution to a specific problem. I am asking for more information about the behavior in general here, and demonstrating how it can be reproduced. (To demonstrate the difference, you can see a fairly long comment thread on the accepted answer where we discussed the behavior, and I felt

问题 This is a follow-up to the question at Slow Postgres 9.3 queries. The new indexes definitely help. But what we're seeing is sometimes queries are much slower in practice than when we run EXPLAIN ANALYZE. An example is the following, run on the production database: explain analyze SELECT * FROM messages WHERE groupid=957 ORDER BY id DESC LIMIT 20 OFFSET 31980; QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------