This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Which is faster/best? SELECT * or SELECT column1, colum2, column3, etc
Is there a big performance impact in doing a SELECT * FROM table_name than doing SELECT specific_columns FROM table_name?
Yes, it affect performances, especially when you select multiple rows.
Select only fields you really need.
Let's take a simple username existance check as example:
Why you'd select everything, when you can select only ID? Both doing the job, but selecting only one field is much better solution.
SELECT `id` FROM users WHERE `username` = 'Nikola K.'
rather than:
SELECT * FROM users WHERE `username` = 'Nikola K.'
I would suggest using EXPLAIN to find the best method to suit your needs. I suppose it would depend on how many columns you have in your table.
The following are some useful sites on MySQL Explain:
http://dev.mysql.com/doc/refman/5.0/en/explain.html
http://dev.mysql.com/doc/refman/5.0/en/using-explain.html
http://weevilgenius.net/2010/09/mysql-explain-reference/
Select only what you need! When in development I use * because it's easier when I don't really know what I'll be needing, but in the final version you really should be specific. Why not?
Related
This question already has answers here:
Why does adding '*' to a MySQL query cause a syntax error?
(3 answers)
Closed 5 years ago.
Sometimes its handy to return all data in a table as well as the data you specifically want e.g.
SELECT *, name, age FROM users;
But it would be more handy to get the data you want first, followed by the remaining data.
SELECT name, age, * FROM users;
However the second SQL statement fails with a syntax error.
Why is this?
I've searched a bit and I found a total of 3 questions on SO that are related to this question or pose the same question. Disclaimer: I only found them by searching for something from the link Damien provided in the comments: "Use of an unqualified * with other items"
You get these SO questions:
Why does adding '*' to a MySQL query cause a syntax error?
Using count(*) and * in the same select clause gives an error. Why?
Confusing SQL error in SELECT NULL, *, NULL, NULL
In the comments on the answer of the last question I found a link to a bug report from 2007 which was closed in 2009 with the following explanation:
I have updated http://dev.mysql.com/doc/refman/5.1/en/select.html to
reflect the behavior:
A select list consisting only of a single unqualified * can be used as
shorthand to select all columns from all tables:
SELECT * FROM t1 INNER JOIN t2 ...
tbl_name.* can be used as a qualified shorthand to select all columns
from the named table:
SELECT t1., t2. FROM t1 INNER JOIN t2 ...
Use of an unqualified * with other items in the select list may
produce a parse error. To avoid this problem, use a qualified
tbl_name.* reference
SELECT AVG(score), t1.* FROM t1 ...
Highlight/Bold provided by me. I couldn't find any further explanation for this behaviour or what kind of parse error could occur or where it would occur.
If someone has some time this could be answered by digging into MySQL's or MariaDB's (which has the same behaviour) source code but short of that I don't see someone finding a real answer to this.
Because mysql is lenient to its syntax, but not always...
Beside, if you want to write a valid SQL query, it should be like that:
select col1, col2, users.*
from users
Or with alias on table and column:
select u.*, 'foobar' as col1, 1 as col2
from users u
On toptal.com I found this question to which they provided the following solution:
SELECT * FROM mytable WHERE a=X UNION ALL SELECT * FROM mytable WHERE b=Y AND a!=X
Can someone explain the usage of X and Y here? Are these variables? Does it also work this way in MySQL? I can't seem to get this kind of query running on a test server.
Also, they make the following claim:
The key is the AND a!=X part. This gives you the benefits of the UNION (a.k.a., UNION DISTINCT) command, while avoiding much of its performance hit.
But if this were true, why would anyone ever use UNION DISTINCT? In particular, why wouldn't it be implemented using this supposedly more efficient way?
The x is just a placeholder in that pseudocode for the 'real' filter. You might know that the field a is the only one that might be duplicated on both sides of your union, but the query optimiser might not, so doing the union in that way is more performance friendly. That answer would only apply in certain circumstances, depending on the context of the data.
It's not a well written question.
You can use a OR in the WHERE clause like this:
SELECT *
FROM mytable
WHERE a=X OR (b=Y AND a!=X);
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
MYSQL OR vs IN performance
I was wondering whats the difference between:
SELECT * FROM table WHERE cat = 'cat1' OR cat = 'cat2' OR cat = 'cat3'
And:
SELECT * FROM table WHERE cat in ('cat1', 'cat2', 'cat3')
Is there any difference? As I tried they both give out same result.
They are identical the IN() is just a short-hand version using listing out all of the OR statements.
IN() just makes for a much shorter, and easier to read, syntax especially when you have a lot of OR clauses.
There is one more thing that you can do quite easily with IN but you can't with =.
SELECT *
FROM `table`
WHERE `column` IN (
SELECT col_name
FROM `table2` -- or the same table
WHERE `some_column` = 5
)
So basically you search in a subset of another table, which sometimes comes in handy.
Real life usage:
You have a list of administrable user types (each with its own permissions) in another table, and you want to enforce that the user type actually exists.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
COUNT() vs. COUNT(1) vs. COUNT(pk): which is better?
count() and count(column_name), what's the diff?
count(*) vs count(column-name) - which is more correct?
The benefit of using count(*) in a select statement is that I can use it with any table and that makes automating scripts easier:
count_sql = 'select count(*) ' + getRestOfSQL('tablename');
But, is it less efficient than using count(specific_field)?
For InnoDB
If specific_field is not nullable, they are equivalent and have the same performance.
If specific_field is nullable, they don't do the same thing. COUNT(specific_field) counts the rows which have a not null value of specific_field. This requires looking at the value of specific_field for each row. COUNT(*) simply counts the number of rows and in this case can be faster as it does not require examining the value of specific_field.
For MyISAM
There is a special optimization for the following so that it does not even need to fetch all rows:
SELECT COUNT(*) FROM yourtable
Generally, it wouldn't matter so much, as we're returning the same number of rows.
This link covers it nicely
count(*) vs count(column-name) - which is more correct?
Count(*) vs Count(1)
This link also explains more, specifically with Oracle
I am trying to conceptualize how to set up UNION of 3 tables that will allow for ordering in a striping fashion.
Top 5 from the UNION of Tables A,B,C
with results ordered like so:
A
B
C
A
B
C
....
Is this sort of thing possibe with SQL and more specifically MySQL?
Personally, I would pull the three queries out separately, and then process through them in your favourite programming language. The queries should run faster like this, as they would not be so complex.
It should be possible using only SQL though, by adding a couple of columns to your output for each of the three queries, and then wrapping the whole lot in an outer select such as;
SELECT * FROM ( <PUT THE FULL UNION HERE> ) ORDER BY table_name, row_count
You'd need to alter each of the queries like this;
##rowCount=0;
SELECT 'A' AS table_name, (##rowCount+1) AS row_count, <remaining fields>
FROM table_A;
Now, I'm not totally sure of the syntax for the incrementing row counter, but I've seen it done elsewhere (probably on StackOverflow somewhere), so maybe someone else can help with that part? (Or you may find the answer by searching this site...)