I have a table that has Many rows up to 1000000. and 300 columns
Question : I would like to know the fastest way to get the max date of the column 'LastModifiedDate in table.
In My table I have the columns : Id, LastModifiedDate and others columns...
Thanks in advance for your help
If the inserted records are the latest LastModifiedDate and this LastModifiedDate column will not change after being written into the table.
I think you can create a Clustered index on the LastModifiedDate column. In a Clustered table, a SQL Server clustered index is used to store the data rows sorted based on the clustered index key values. You can referance this documentation Designing effective SQL Server clustered indexes.
Put an index on the column and use:
select max(LastModifiedDate)
from t;
If you want the complete row with the largest date:
select top (1) t.*
from t
order by LastModifiedDate desc;
Related
How would I sort a table in SQL Server when it is opened? My table has an autonumber field that increments sequentially and it is the primary key field also.
I'd like to have another numeric field sorted smallest to largest and then have the autonumber field to use the auto field number relying on the other numeric field.
The image shows how the table is currently sorted. I'd like to have the table sorted when it opens from ssms by the second column.
Thanks,
Jeff
the sort depends on cluster index, by default any primary key will create a clustered index on that column so the table will be sorted based on it.
if you want to sort the table based on another column you need to drop your cluster index and create it on the second column.
How would I sort a table in SQL Server when it is opened?
You cannot. SQL tables represent unordered (multi)sets. They have no inherent ordering. To get data in order, you need an explicit order by clause:
select t.*
from t
order by col2 asc;
For performance, you want an index on (col2).
If you declared the second column as a descending clustered index, then in practice you would probably see smaller values first. However, even with a clustered index, SQL Server does not guarantee that a SELECT with no ORDER BY will return the rows in any order. Period. There is no guarantee.
I want to sort my table permanently by using ID column in ascending order.
select * from CLAIMS order by ID asc; gives me the result in ascending order.
But I want to permanently change my table. I am using SQL Management Studio 2014.
While there's no way to guarantee ordered result without an ORDER BY clause on your query, but you can store the rows in a sorted order to enable the SQL Server to run
select * from CLAIMS order by ID asc;
without having to perform a sort every time. To to that simply create a clustered index with ID as the only or the leading column.
EG
alter table CLAIMS add constraint PK_CLAIMS primary key clustered (ID)
or
create unique clustered index AK_CLAIMS on CLAIMS(ID)
I want to sort my table permanently
You just can't. SQL tables represent unordered set of rows. There is no inherent ordering of rows in a table, as you seem to assume.
If you want the rows returned in a given order for a given query, then do add an order by clause to the query:
select * from claims order by id
If you don't provide an order by clause, the database is free to return the rows in whichever order it likes. The ordering you see today for a given query might change unexpectedly in the future.
SQL Server 1 million records: best way to get fastest last record of table?
Example: I have a table A with 1 million records. What is the way to get fastest last records?
I know: SELECT TOP 1 * FROM A ORDER BY ID DESC
But I think It's not good way for me.
The query in your question will perform very well if you have a clustered index (which may be the primary key index) on ID. There is no faster way to retrieve all columns from a single row of a table.
I'll add that a table is logically an unordered set of rows so ORDER BY is required to return a "last" or "first" row. The b-tree index on the ORDER BY column will locate the row efficiently.
you have only one way index on primary key and where values . order by has a little bit cost but it's ok if you has index on order Column
--ORDER BY 1 DESC means order by primary key index desc
SELECT [Columns] FROM [TABLENAME] ORDER BY 1 DESC
--or you can use this if your first column is IDENTITY or A/A
SELECT [Columns] FROM [TABLENAME] ORDER BY [YOUR_COLUMN_WITHA/A ] DESC
I've a large (> 100 million rows) table in my MS SQL database with the following columns:
Id int not null,
ObjectId int not null,
Timestamp datetime not null
State int not null
Id it the primary key of the table (and has a clustered index on it). I added a non clustered index on Timestamp and ObjectId (in this order). There are just around 2000 distinct values in ObjectId. I want now perform the following query:
SELECT ObjectId, MAX(Timestamp) FROM Table GROUP BY ObjectId
It takes something around four seconds, which is too slow for my application. The execution plan says that 97% of the runtime goes to an Index Scan of the non clustered index.
On a copy of the table I created a clustered index on ObjectId and Timestamp. The resulting runtime is same, the execution plan says its doing now a Index Scan of the clustered index.
Is there any other possibility to improve the runtime without splitting the table's data into multiple tables?
I can propose you another answer, add a boolean column LAST and update last true for the ObjectID to false before insert now row for this ObjectID with LAST to true. Create an index on ObjectID and LAST. Query very simple :
SELECT ObjectId, Timestamp FROM Table where LAST = true
No more group by and fullscan but one more update each for insert.
4 seconds in not bad for that kind on work in DB with more 100M rows.
You can archive daily some data in another table to preserve historic. You can archive all data in another table and delete old changing of objects :
delete from TABLE where Id in (select t1.Id from Table t1, Table t2
where t1.ObjectId = t2.ObjectId and t1.Timestamp < t2.Timestamp )
For this particular query, an index on (ObjectId, Timestamp) will be optimal. And there is a chance that (ObjectId, Timestamp DESC) will perform even faster.
Not sure if this is possible in PostgreSQL 9.3+, but I'd like to create a unique index on a non-unique column. For a table like:
CREATE TABLE data (
id SERIAL
, day DATE
, val NUMERIC
);
CREATE INDEX data_day_val_idx ON data (day, val);
I'd like to be able to [quickly] query only the distinct days. I know I can use data_day_val_idx to help perform the distinct search, but it seems this adds extra overhead if the number of distinct values is substantially less than the number of rows in the index covers. In my case, about 1 in 30 days is distinct.
Is my only option to create a relational table to only track the unique entries? Thinking:
CREATE TABLE days (
day DATE PRIMARY KEY
);
And update this with a trigger every time we insert into data.
An index can only index actual rows, not aggregated rows. So, yes, as far as the desired index goes, creating a table with unique values like you mentioned is your only option. Enforce referential integrity with a foreign key constraint from data.day to days.day. This might also be best for performance, depending on the complete situation.
However, since this is about performance, there is an alternative solution: you can use a recursive CTE to emulate a loose index scan:
WITH RECURSIVE cte AS (
( -- parentheses required
SELECT day FROM data ORDER BY 1 LIMIT 1
)
UNION ALL
SELECT (SELECT day FROM data WHERE day > c.day ORDER BY 1 LIMIT 1)
FROM cte c
WHERE c.day IS NOT NULL -- exit condition
)
SELECT day FROM cte;
Parentheses around the first SELECT are required because of the attached ORDER BY and LIMIT clauses. See:
Combining 3 SELECT statements to output 1 table
This only needs a plain index on day.
There are various variants, depending on your actual queries:
Optimize GROUP BY query to retrieve latest row per user
Unused index in range of dates query
Select first row in each GROUP BY group?
More in my answer to your follow-up querstion:
Counting distinct rows using recursive cte over non-distinct index