Simple select where query runs faster WITHOUT primary key
I have two tables with the same data structure except that one has a primary key on a column and the other don't.
The thing is, query on the table with primary key run in average 6x to 10x slower than the one without primary key..
Table without PK
CREATE TABLE `ULRCON01`
(
`CONSTAC` VARCHAR ( 7 ) NOT NULL,
`DATCRED` VARCHAR ( 8 ),
`DATMAJD` VARCHAR ( 8 ),
`MONTANM` DECIMAL ( 19 ),
`CONSTLC` VARCHAR ( 10 ),
`CONSTLL` VARCHAR ( 35 ),
);
Table with PK
CREATE TABLE `ULRCON01`
(
`CONSTAC` VARCHAR ( 7 ) NOT NULL,
`DATCRED` VARCHAR ( 8 ),
`DATMAJD` VARCHAR ( 8 ),
`MONTANM` DECIMAL ( 19 ),
`CONSTLC` VARCHAR ( 10 ),
`CONSTLL` VARCHAR ( 35 ),
PRIMARY KEY(`CONSTAC`)
);
The query
SELECT CONSTLC FROM ULRCON01 WHERE CONSTAC LIKE 'SIRCA00'
And the results..
// PK on CONSTAC
Request "SELECT CONSTLC FROM ULRCON01 WHERE CONSTAC LIKE 'SIRCA00'" executed in 10ms
// No PK
Request "SELECT CONSTLC FROM ULRCON01 WHERE CONSTAC LIKE 'SIRCA00'" executed in 1ms
I just don't understand.. Why would primary key slow down a simple select where query.. Any ideas ?
sqlite
|
show 2 more comments
I have two tables with the same data structure except that one has a primary key on a column and the other don't.
The thing is, query on the table with primary key run in average 6x to 10x slower than the one without primary key..
Table without PK
CREATE TABLE `ULRCON01`
(
`CONSTAC` VARCHAR ( 7 ) NOT NULL,
`DATCRED` VARCHAR ( 8 ),
`DATMAJD` VARCHAR ( 8 ),
`MONTANM` DECIMAL ( 19 ),
`CONSTLC` VARCHAR ( 10 ),
`CONSTLL` VARCHAR ( 35 ),
);
Table with PK
CREATE TABLE `ULRCON01`
(
`CONSTAC` VARCHAR ( 7 ) NOT NULL,
`DATCRED` VARCHAR ( 8 ),
`DATMAJD` VARCHAR ( 8 ),
`MONTANM` DECIMAL ( 19 ),
`CONSTLC` VARCHAR ( 10 ),
`CONSTLL` VARCHAR ( 35 ),
PRIMARY KEY(`CONSTAC`)
);
The query
SELECT CONSTLC FROM ULRCON01 WHERE CONSTAC LIKE 'SIRCA00'
And the results..
// PK on CONSTAC
Request "SELECT CONSTLC FROM ULRCON01 WHERE CONSTAC LIKE 'SIRCA00'" executed in 10ms
// No PK
Request "SELECT CONSTLC FROM ULRCON01 WHERE CONSTAC LIKE 'SIRCA00'" executed in 1ms
I just don't understand.. Why would primary key slow down a simple select where query.. Any ideas ?
sqlite
That data are probably cached for the second run. Have you tried reversing the order?
– John Wu
Nov 9 '18 at 15:49
The two queries are not runned in the same instance. I do the first one, then exit, change the table, re-build and run the same test :/
– Sebastien Servouze
Nov 9 '18 at 15:52
Have you tried using=
instead ofLIKE
?
– John Wu
Nov 9 '18 at 16:11
2
After fixing the syntax error in the first table definition, the select query compiles to the same sequence of bytecode instructions for the two table definitions, so they should be running in about the same time. I suspect the problem lies in something you're not showing or mentioning.
– Shawn
Nov 9 '18 at 18:46
Also, since you're using varchar and decimal in your table definitions, you should read this: sqlite.org/datatype3.html
– Shawn
Nov 9 '18 at 18:48
|
show 2 more comments
I have two tables with the same data structure except that one has a primary key on a column and the other don't.
The thing is, query on the table with primary key run in average 6x to 10x slower than the one without primary key..
Table without PK
CREATE TABLE `ULRCON01`
(
`CONSTAC` VARCHAR ( 7 ) NOT NULL,
`DATCRED` VARCHAR ( 8 ),
`DATMAJD` VARCHAR ( 8 ),
`MONTANM` DECIMAL ( 19 ),
`CONSTLC` VARCHAR ( 10 ),
`CONSTLL` VARCHAR ( 35 ),
);
Table with PK
CREATE TABLE `ULRCON01`
(
`CONSTAC` VARCHAR ( 7 ) NOT NULL,
`DATCRED` VARCHAR ( 8 ),
`DATMAJD` VARCHAR ( 8 ),
`MONTANM` DECIMAL ( 19 ),
`CONSTLC` VARCHAR ( 10 ),
`CONSTLL` VARCHAR ( 35 ),
PRIMARY KEY(`CONSTAC`)
);
The query
SELECT CONSTLC FROM ULRCON01 WHERE CONSTAC LIKE 'SIRCA00'
And the results..
// PK on CONSTAC
Request "SELECT CONSTLC FROM ULRCON01 WHERE CONSTAC LIKE 'SIRCA00'" executed in 10ms
// No PK
Request "SELECT CONSTLC FROM ULRCON01 WHERE CONSTAC LIKE 'SIRCA00'" executed in 1ms
I just don't understand.. Why would primary key slow down a simple select where query.. Any ideas ?
sqlite
I have two tables with the same data structure except that one has a primary key on a column and the other don't.
The thing is, query on the table with primary key run in average 6x to 10x slower than the one without primary key..
Table without PK
CREATE TABLE `ULRCON01`
(
`CONSTAC` VARCHAR ( 7 ) NOT NULL,
`DATCRED` VARCHAR ( 8 ),
`DATMAJD` VARCHAR ( 8 ),
`MONTANM` DECIMAL ( 19 ),
`CONSTLC` VARCHAR ( 10 ),
`CONSTLL` VARCHAR ( 35 ),
);
Table with PK
CREATE TABLE `ULRCON01`
(
`CONSTAC` VARCHAR ( 7 ) NOT NULL,
`DATCRED` VARCHAR ( 8 ),
`DATMAJD` VARCHAR ( 8 ),
`MONTANM` DECIMAL ( 19 ),
`CONSTLC` VARCHAR ( 10 ),
`CONSTLL` VARCHAR ( 35 ),
PRIMARY KEY(`CONSTAC`)
);
The query
SELECT CONSTLC FROM ULRCON01 WHERE CONSTAC LIKE 'SIRCA00'
And the results..
// PK on CONSTAC
Request "SELECT CONSTLC FROM ULRCON01 WHERE CONSTAC LIKE 'SIRCA00'" executed in 10ms
// No PK
Request "SELECT CONSTLC FROM ULRCON01 WHERE CONSTAC LIKE 'SIRCA00'" executed in 1ms
I just don't understand.. Why would primary key slow down a simple select where query.. Any ideas ?
sqlite
sqlite
edited Nov 9 '18 at 16:06
Diado
1,39221015
1,39221015
asked Nov 9 '18 at 15:46
Sebastien ServouzeSebastien Servouze
317110
317110
That data are probably cached for the second run. Have you tried reversing the order?
– John Wu
Nov 9 '18 at 15:49
The two queries are not runned in the same instance. I do the first one, then exit, change the table, re-build and run the same test :/
– Sebastien Servouze
Nov 9 '18 at 15:52
Have you tried using=
instead ofLIKE
?
– John Wu
Nov 9 '18 at 16:11
2
After fixing the syntax error in the first table definition, the select query compiles to the same sequence of bytecode instructions for the two table definitions, so they should be running in about the same time. I suspect the problem lies in something you're not showing or mentioning.
– Shawn
Nov 9 '18 at 18:46
Also, since you're using varchar and decimal in your table definitions, you should read this: sqlite.org/datatype3.html
– Shawn
Nov 9 '18 at 18:48
|
show 2 more comments
That data are probably cached for the second run. Have you tried reversing the order?
– John Wu
Nov 9 '18 at 15:49
The two queries are not runned in the same instance. I do the first one, then exit, change the table, re-build and run the same test :/
– Sebastien Servouze
Nov 9 '18 at 15:52
Have you tried using=
instead ofLIKE
?
– John Wu
Nov 9 '18 at 16:11
2
After fixing the syntax error in the first table definition, the select query compiles to the same sequence of bytecode instructions for the two table definitions, so they should be running in about the same time. I suspect the problem lies in something you're not showing or mentioning.
– Shawn
Nov 9 '18 at 18:46
Also, since you're using varchar and decimal in your table definitions, you should read this: sqlite.org/datatype3.html
– Shawn
Nov 9 '18 at 18:48
That data are probably cached for the second run. Have you tried reversing the order?
– John Wu
Nov 9 '18 at 15:49
That data are probably cached for the second run. Have you tried reversing the order?
– John Wu
Nov 9 '18 at 15:49
The two queries are not runned in the same instance. I do the first one, then exit, change the table, re-build and run the same test :/
– Sebastien Servouze
Nov 9 '18 at 15:52
The two queries are not runned in the same instance. I do the first one, then exit, change the table, re-build and run the same test :/
– Sebastien Servouze
Nov 9 '18 at 15:52
Have you tried using
=
instead of LIKE
?– John Wu
Nov 9 '18 at 16:11
Have you tried using
=
instead of LIKE
?– John Wu
Nov 9 '18 at 16:11
2
2
After fixing the syntax error in the first table definition, the select query compiles to the same sequence of bytecode instructions for the two table definitions, so they should be running in about the same time. I suspect the problem lies in something you're not showing or mentioning.
– Shawn
Nov 9 '18 at 18:46
After fixing the syntax error in the first table definition, the select query compiles to the same sequence of bytecode instructions for the two table definitions, so they should be running in about the same time. I suspect the problem lies in something you're not showing or mentioning.
– Shawn
Nov 9 '18 at 18:46
Also, since you're using varchar and decimal in your table definitions, you should read this: sqlite.org/datatype3.html
– Shawn
Nov 9 '18 at 18:48
Also, since you're using varchar and decimal in your table definitions, you should read this: sqlite.org/datatype3.html
– Shawn
Nov 9 '18 at 18:48
|
show 2 more comments
1 Answer
1
active
oldest
votes
Ok, so after more investigation, it cames from the way we are using SQLiteDataReader..
We specified
using (var myReader = sqlCmd.ExecuteReader(CommandBehavior.KeyInfo))
And it's quite costfull (also that's why it runs faster without primary keys..). So now we use
using (var myReader = sqlCmd.ExecuteReader(CommandBehavior.Default))
Which speed up the request to 2ms instead of 10 !
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53228956%2fsimple-select-where-query-runs-faster-without-primary-key%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Ok, so after more investigation, it cames from the way we are using SQLiteDataReader..
We specified
using (var myReader = sqlCmd.ExecuteReader(CommandBehavior.KeyInfo))
And it's quite costfull (also that's why it runs faster without primary keys..). So now we use
using (var myReader = sqlCmd.ExecuteReader(CommandBehavior.Default))
Which speed up the request to 2ms instead of 10 !
add a comment |
Ok, so after more investigation, it cames from the way we are using SQLiteDataReader..
We specified
using (var myReader = sqlCmd.ExecuteReader(CommandBehavior.KeyInfo))
And it's quite costfull (also that's why it runs faster without primary keys..). So now we use
using (var myReader = sqlCmd.ExecuteReader(CommandBehavior.Default))
Which speed up the request to 2ms instead of 10 !
add a comment |
Ok, so after more investigation, it cames from the way we are using SQLiteDataReader..
We specified
using (var myReader = sqlCmd.ExecuteReader(CommandBehavior.KeyInfo))
And it's quite costfull (also that's why it runs faster without primary keys..). So now we use
using (var myReader = sqlCmd.ExecuteReader(CommandBehavior.Default))
Which speed up the request to 2ms instead of 10 !
Ok, so after more investigation, it cames from the way we are using SQLiteDataReader..
We specified
using (var myReader = sqlCmd.ExecuteReader(CommandBehavior.KeyInfo))
And it's quite costfull (also that's why it runs faster without primary keys..). So now we use
using (var myReader = sqlCmd.ExecuteReader(CommandBehavior.Default))
Which speed up the request to 2ms instead of 10 !
answered Nov 13 '18 at 10:04
Sebastien ServouzeSebastien Servouze
317110
317110
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53228956%2fsimple-select-where-query-runs-faster-without-primary-key%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
That data are probably cached for the second run. Have you tried reversing the order?
– John Wu
Nov 9 '18 at 15:49
The two queries are not runned in the same instance. I do the first one, then exit, change the table, re-build and run the same test :/
– Sebastien Servouze
Nov 9 '18 at 15:52
Have you tried using
=
instead ofLIKE
?– John Wu
Nov 9 '18 at 16:11
2
After fixing the syntax error in the first table definition, the select query compiles to the same sequence of bytecode instructions for the two table definitions, so they should be running in about the same time. I suspect the problem lies in something you're not showing or mentioning.
– Shawn
Nov 9 '18 at 18:46
Also, since you're using varchar and decimal in your table definitions, you should read this: sqlite.org/datatype3.html
– Shawn
Nov 9 '18 at 18:48