I have a table, where one column is sorted. Does MySQL somehow check if it's sorted or not? If I make such a query SELECT from tab WHERE col1>890 AND col1<74893798 where the col1 is sorted, is it the same as e.g. SELECT from tab WHERE id>16 AND id<798176
I was unable to test this properly because of lack of admin rights to flush the query cache.
To make it clear, the col1 is sorted, because it was inserted there from another table which had been sorted by the column.
No, it is not sorted by the column you use on your where clause. The id records look sorted because that's probably your primary key and already dictates the position of the data in your table. You need to add ORDER BY column if you want your data sorted
MySQL does not sort results by default (What drive the natural result order for an unordered MySQL request). Generally, Relational DataBase Management Systems (RDBMS) do not guarantee any specific row order unless you specify an order with an ORDER BY clause.
The advantage of this is that the database may internally sort data in whatever format it deems to be most optimal.
Related
I'm working with MySQL 5.6. In all of my use-cases I build a read-only table to then query.
The common use-case of my customers is to sort results by insertion order. We even added a column with index that defines insertion order. The dilemma is if we should inject an "ORDER BY" to queries (unless another sort was requested by users).
One of the guys said it might hurt performance, which sounds reasonable. He also said that there is no configuration that ensures table's order since table might be updates - although in our case the table is always read-only.
Is there a way to define a read-only table that does ensure a specific order to avoid injecting "ORDER BY" in every query? Meaning it will somehow save the table in a defined order to avoid performance penalty?
Will be happy for any suggestions.
Thanks in advance.
No. SQL tables represent unordered sets. There is no ordering in the table unless you specify an order by.
What you can do is have an index on the column you want to order by. Then, MySQL does not actually need to sort the data -- it just needs to read the index. Or, if you can, you can make the column you want to order by a primary key. This makes sense if your column is really an auto_increment column.
Does anyone answer me why MySQL table raw id not serially?
MySQL will try to give you the results as quick as it can, based on your query.
If you didn't tell MySQL to sort on any field, MySQL will probably pick the order in which it's sorted on the disk.
Records in mysql aren't always stored in order on disk. An example where they might go out of order is if you delete a record in the middle of the table. The next record might (for space saving reasons) be inserted in the position where you deleted a record earlier.
Don't worry about this. This is normal. If you create an application that uses MySQL, make sure you include ORDER BY id at the end of your query to get your predictable order.
If you don't use an ORDER BY clause to make your desired order explicit, the query results are up to the implementation. That means MySQL gets to choose the order if you don't.
In the case of MyISAM tables, the default order is the order rows are stored in the table, which can get mixed up over time as rows are added and deleted. New rows may fit into gaps left by deleted rows, even if that makes them stored "out of order".
In the case of InnoDB tables, the default order is by the index used to read the rows. This is often the primary key, but it might not be. It depends on your table definition and the SQL query you use to read the rows.
Just use ORDER BY if you want the rows ordered by a specific column.
I have the following query
SELECT *
FROM table_1
INNER JOIN table_2 ON table_1.orders = table_2.orders
ORDER BY table_2.purchasetime;
The above query result is indeterminate i.e it can change with different queries when the purchase time is of same value as per the MySQL manual itself.To overcome this we give sort ordering on a unique column and combine it with the regular sort ordering.
The customer does not want to see different results with different page refreshes so we have put in the above fix specifically for MySQL which is unnecessary and needs extra compound indexes for both asc and desc.
I am not sure whether the same is applicable for postgres.So far I have not been able to reproduce the scenario.I would appreciate if someone could answer this for postgres or point me in the right direction.
Edit 1 : The sort column is indexed.So assuming the disk data has no ordering, but in the case of index (btree data structure) a constant ordering might be possible with postgres ?
No, it will not be different in PostgreSQL (or, in fact, in any other relational database that I know of).
See http://www.postgresql.org/docs/9.4/static/queries-order.html :
After a query has produced an output table (after the select list has been processed) it can optionally be sorted. If sorting is not chosen, the rows will be returned in an unspecified order. The actual order in that case will depend on the scan and join plan types and the order on disk, but it must not be relied on. A particular output ordering can only be guaranteed if the sort step is explicitly chosen.
Even if by accident you manage to find a PostgreSQL version and index that will guarantee the order in all the test you run, please don't rely on it. Any database upgrade, data change or a change in the Maya calendar or the phase of the moon can suddenly upset your sorting order. And debugging it then is a true and terrible pain in the neck.
Your concern seems to be that order by table_2.purchasetime is indeterminate when there are multiple rows with the same value.
To fix this -- in any database or really any computer language -- you need a stable sort. You can turn any sort into a stable sort by adding a unique key. So, adding a unique column (typically an id of some sort) fixes this in both MySQL and Postgres (and any other database).
I should note that instability in sorts can be a very subtle problem, one that only shows up under certain circumstances. So, you could run the same query many times and it is fine. Then you insert or delete a record (perhaps even one not chosen by the query) and the order changes.
this is the front-end http://jsfiddle.net/JRwM7/2/
I thought of just insert normally (using order by) then do the sorting in the front-end, but I curious and wanted to know is there any method of query to have a sorted data in my db table.
A table is a set (of rows), and sets are inherently unordered. Logically, the only way to guarantee an order of rows returned from some query is to use ORDER BY clause.
On the physical level, if ORDER BY clause happens to match an index, the DBMS might be able to establish the order by just traversing the index's B-Tree instead of performing a separate sort, which may benefit performance.
insert normally (using order by)
I'm not sure what you mean by that? ORDER BY is not valid syntax for INSERT INTO.
When selecting columns from a MySQL table, is performance affected by the order that you select the columns as compared to their order in the table (not considering indexes that may cover the columns)?
For example, you have a table with rows uid, name, bday, and you have the following query.
SELECT uid, name, bday FROM table
Does MySQL see the following query any differently and thus cause any sort of performance hit?
SELECT uid, bday, name FROM table
The order doesn't matter, actually, so you are free to order them however you'd like.
edit: I guess a bit more background is helpful: As far as I know, the process of optimizing any query happens prior to determining exactly what subset of the row data is being pulled. So the query optimizer breaks it down into first what table to look at, joins to perform, indexes to use, aggregates to apply, etc., and then retrieves that dataset. The column ordering happens between the data pull and the formation of the result set, so the data actually "arrives" as ordered by the database, and is then reordered as it is returned to your application.
In practice, I suspect it might.
With a decent query optimiser: it shouldn't.
You can only tell for your cases by measuring. And the measurements will likely change as the distribution of data changes in the database.
with regards
Wazzy
The order of the attributes selected is negligible. The underlying storage engines surely order their attribute locations, but you would not necessarily have a way to know the specific ordering (renames, alter tables, row vs. column stores) in most cases may be independent from the table description which is just meta data anyway. The order of presentation into the result set would be insignificant in terms of any measurable overhead.