I have a table that is indexed on the first 2 columns. Column A is called "directory" and Column B is called "name".
Is there short syntax for my select statement that I can use to return the proper row?
Example:
Can I
SELECT * FROM table WHERE indexname = '/dir/sub-dir/page.html'
or do I have to
SELECT * FROM table WHERE directory = '/dir/sub-dir/' AND name = 'page.html'
If I can use the first example, what does the WHERE clause look like?
Thanks.
If you have an index defined against both columns, the second usage is the proper one. In SQL, you can only define predicates against columns in tables, views, or table valued user-defined functions (which I don't think MySQL has yet). You can't select off an index, but the optimizer will know to use the appropriate index when you include both columns.
Related
I need to select a value from a column in the table as a name of the another column in mysql
for ex ::
select column AS (select column from table where id = 1) from table;
it give me a syntax error .. How can I use select statement inside AS Function
Actually I need to set a value from a column as a name to another column using AS Function in mysql
The answer is simple: It is not possible in SQL. Column aliases are constants.
You can't do this in a single query. All identifiers must be fixed in the query at the time it is parsed, which is before the query begins reading data. This includes column names and column aliases. The names or aliases of columns cannot be set at runtime based on data read during the query.
But you can do what you want in two queries.
Query to get the column alias name you want to use. This returns a string.
Use that string as you format the second query. Then the column alias will be fixed in that second query by the time you prepare it.
I have a table with two fields: a,b
Both fields are indexed separately -- no compound index.
While trying to run a select query with both fields:
select * from table where a=<sth> and b=<sth>
It took over 400ms. while
select * from table where a=<sth>
took only 30ms;
Do I need set a compound index for (a,b)?
Reasonably, if I have indexes on both a and b, it should be fast for queries of a AND b like above right?
For this query:
select *
from table
where a = <sth> and b = <sth>;
The best index is on table(a, b). This can also be used for your second query as well.
Usually (but not always).
In your case the number of different values in a (and b) and the number of columns you use in your select can change the way db decide to use index / table.
For example,
if in table you have,say, 100.000 records and 80.000 of them have the same value for a, when you query for:
SELECT * FROM table WHERE a=<your value>
db engine could decide to "scan" directly the table without using the index, while if you query
SELECT a, b FROM table WHERE a=<your value>
and in index you added column b too (in index directly or with INCLUDE) it's quite probable that db engine will use the index.
Try to give a look on internet for index tips and give a look too to How can I index these queries?
The SQLite documentation explains how index lookups work.
Once the database has used an index to look up some rows, the other index is no longer efficient to use (there is no easy method to filter the results of the first lookup because the other index refers to rows in the original table, not to entries in the first index). See Multiple AND-Connected WHERE-Clause Terms.
To make index lookups on two columns as fast as possible, you need Multi-Column Indices.
I would like to know if it is necessary to create an index for all fields within a table if one of your queries will use SELECT *.
To explain, if we had a table that 10M records and we did a SELECT * query on it would the query run faster if we have created an index for all fields within the table or does MySQL handle SELECT * in a different way to SELECT first_field, a_field, last_field.
To my understanding, if I had a query that did SELECT first_field, a_field FROM table then it would bring performance benefits if we created an index on first_field, a_field but if we use SELECT * is there even a benefit from creating an index for all fields?
Performing a SELECT * FROM mytable query would have to read all the data from the table. This could, theoretically, be done from an index if you have an index on all the columns, but it would be just faster for the database to read the table itself.
If you have a where clause, having an index on (some of) the columns you have conditions on may dramatically improve the query's performance. It's a gross simplification, but what basically happens is the following:
The appropriate rows are filtered according to the where clause. It's much faster to search for these rows in an index (which is, essentially, a sorted tree) than a table (which is an unordered set of rows).
For the columns that where in the index used in the previous step the values are returned.
For the columns that aren't, the table is accessed (according to a pointer kept in the index).
indexing a mysql table for a column improves performance when there is a need to search or edit a row/record based on that column of that table.
for example, if there is an 'id' column and if it is a primary key; And in that case if you want to search a record using where clause on that 'id' column then you don't need to create index for the 'id' column because primary key column will act as an indexed column.
In another case, if there is an 'pid' column in the table and if it is not a primary key; Then in order to search based on 'pid' column then to improve performance it is better to create an index for the 'pid' column. That will make query fast to search the expected record.
Assume I have this table:
create table table_a (
id int,
name varchar(25),
address varchar(25),
primary key (id)
) engine = innodb;
When I run this query:
select * from table_a where id >= 'x' and name = 'test';
How will MySQL process it? Will it pull all the id's first (assume 1000 rows) then apply the where clause name = 'test'?
Or while it looks for the ids, it is already applying the where clause at the same time?
As id is the PK (and no index on name) it will load all rows that satisfy the id based criterion into memory after which it will filter the resultset by the name criterion. Adding a composite index containing both fields would mean that it would only load the records that satisfy both criteria. Adding a separate single column index on the name field may not result in an index merge operation, in which case the index would have no effect.
Do you have indexes on either column? That may affect the execution plan. The other thing is one might cast the 'x'::int to ensure a numeric comparison instead of a string comparison.
For the best result, you should have a single index which includes both of the columns id and name.
In your case, I can't answer the affect of the primary index to that query. That depends on DBMS's and versions. If you really don't want to put more index (because more index means slow write and updates) just populate your table with like 10.000.000 random results, try it and see the effect.
you can compare the execution times by executing the query first when the id comes first in the where clause and then interchange and bring the name first. to see an example of mysql performance with indexes check this out http://www.mysqlperformanceblog.com/2006/06/02/indexes-in-mysql/
You can get information on how the query is processed by running EXPLAIN on the query.
If the idea is to optimize that query then you might want to add an index like:
alter table table_a add unique index name_id_idx (name, id);
I've noticed that in PHPMyAdmin I can individually index columns or I can use checkboxes to select fields and then click index and they're indexed in a different way. Does this mean that if for a given table I have 2 columns of that table that define each row as unique (instead of just a simple single column id`) I should index those together to increase performance?
A multiple-column index can be considered a sorted array containing values that are created by concatenating the values of the indexed columns.
MySQL uses multiple-column indexes in such a way that queries are fast when you specify a known quantity for the first column of the index in a WHERE clause, even if you do not specify values for the other columns.
If you have two columns named last_name and first_name and you create an index INDEX name (last_name,first_name), The index can be used for queries that specify values in a known range for last_name, or for both last_name and first_name.
Source: http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html
So, it may not be helpful in your particular case. Becuase if you want to query on the later columns (for example: SELECT * FROM test WHERE first_name='Michael' or SELECT * FROM test WHERE last_name='Widenius' OR first_name='Michael), the index will not be used and the queries will be slower.