Which one is fast either Index or View both are used for optimization purpose both are implement on table's column so any one explain which one is more faster and what is difference between both of them and which scenario we use view and index.
VIEW
View is a logical table. It is a physical object which stores data logically. View just refers to data that is tored in base tables.
A view is a logical entity. It is a SQL statement stored in the database in the system tablespace. Data for a view is built in a table created by the database engine in the TEMP tablespace.
INDEX
Indexes are pointres that maps to the physical address of data. So by using indexes data manipulation becomes faster.
An index is a performance-tuning method of allowing faster retrieval of records. An index creates an entry for each value that appears in the indexed columns.
ANALOGY:
Suppose in a shop, assume you have multiple racks. Categorizing each rack based on the items saved is like creating an index. So, you would know where exactly to look for to find a particular item. This is indexing.
In the same shop, you want to know multiple data, say, the Products, inventory, Sales data and stuff as a consolidated report, then it can be compared to a view.
Hope this analogy explains when you have to use a view and when you have to use an index!
Both are different things in the perspective of SQL.
VIEWS
A view is nothing more than a SQL statement that is stored in the database with an associated name. A view is actually a composition of a table in the form of a predefined SQL query.
Views, which are kind of virtual tables, allow users to do the following:
A view can contain all rows of a table or select rows from a table. A view can be created from one or many tables which depends on the written SQL query to create a view.
Structure data in a way that users or classes of users find natural or intuitive.
Restrict access to the data such that a user can see and (sometimes) modify exactly what they need and no more.
Summarize data from various tables which can be used to generate reports.
INDEXES
While Indexes are special lookup tables that the database search engine can use to speed up data retrieval. Simply put, an index is a pointer to data in a table. An index in a database is very similar to an index in the back of a book.
For example, if you want to reference all pages in a book that discuss a certain topic, you first refer to the index, which lists all topics alphabetically and are then referred to one or more specific page numbers.
An index helps speed up SELECT queries and WHERE clauses, but it slows down data input, with UPDATE and INSERT statements. Indexes can be created or dropped with no effect on the data.
view:
1) view is also a one of the database object.
view contains logical data of a base table.where base table has actual data(physical data).another way we can say view is like a window through which data from table can be viewed or changed.
2) It is just simply a stored SQL statement with an object name. It can be used in any SELECT statement like a table.
index:
1) indexes will be created on columns.by using indexes the fetching of rows will be done quickly.
2) It is a way of cataloging the table-info based on 1 or more columns. One table may contain one/more indexes. Indexes are like a 2-D structure having ROWID & indexed-column (ordered). When a table-data is retrieved based on this column (col. which are used in WHERE clause), this index gets into the picture automatically and it's pointer search the required ROWIDs. These ROWIDs are now matched with actual table's ROWID and the records from table are shown.
Related
I've been doing a little research on the MySQL index key for possible database query performance. I have a specific question that hasn't really been answered.
Can you index every field in a table? Or should you just stick to indexing fields that will be in your WHERE clause?
Thanks, sorry if this question has been answered before.
A database index is a data structure that improves the speed of data
retrieval operations on a database table at the cost of additional
writes and storage space to maintain the index data structure. Indexes
are used to quickly locate data without having to search every row in
a database table every time a database table is accessed. Indexes can
be created using one or more columns of a database table, providing
the basis for both rapid random lookups and efficient access of
ordered records.
https://en.wikipedia.org/wiki/Database_index
You should not create INDEX on every fields of table. Use only column which is used for search purpose (i.e WHERE, JOIN).
Note: Index helps to SEARCH faster on table on other hand it has to perform additional INSERT, DELETE and UPDATE so it increase the cost of query.
Consider scenario: You 3 or n queries with 3 or n different fields on same table in this case how to choose index?
It depends on how many times you are executing particular query on table. If you are executing 2 queries very rare then don't create index on that two columns. Create index only on column which is used in query that is executing multiple times.
I have a 8.6M table, with full text search but it is still impossible to use it. I can split this table in two, but I think there must be a better way to use it.
I tried to create a view, with temptable algorithms but it didn't create a physical table.
Table 1 - 8.6M rows
id name age
1 john 20
2 jean 25
View 1 - 200K rows - Only records where age = 25.
id name age
2 jean 25
In MySQL, views are not "materialized views." Every time you query the view, it's like querying the base table. Some other RDBMS products have materialized views, where the subset of the table is also stored, but MySQL does not have this feature.
You have misunderstood the temptable algorithm for views. That means it creates a temporary table every time you query the view. This is probably not going to improve performance.
I'm not sure why you say that it's impossible to use the table. Do you mean that queries are not fast enough? That's not really the biggest table that MySQL can handle. There are tables that have hundreds of millions of rows and are still usable.
You may need different indexes to serve your query. You might benefit from partitioning (although I don't think table partitioning is compatible with fulltext indexes). You might need server hardware with more RAM or CPU horsepower.
If fulltext searches are important, you could also consider copying searchable data to a fulltext search technology like Sphinx Search. See my presentation Full Text Search Throwdown.
if you want a view then create a VIEW like here: http://dev.mysql.com/doc/refman/5.0/en/create-view.html
CREATE VIEW ....
If you want a temporary table then create a temporary table like here: http://dev.mysql.com/doc/refman/5.1/en/create-table.html
CREATE TEMPORARY TABLE ...
A view is permanent, but it is a view, not a table. Meaning that it will only execute a sql statement for you in the background each time you access it. Its purposes and role are not just to make your queries to look prettier but for example to be like a filter that will hide certain information.
A view will be accessible all the time. A temporary table has to be create within the DB connection cycle in order to be used.
Hopefully this answer will help you to decide what you really need - What to use? View or temporary Table
I have 4 databases with tables having lots of data. My requirement is to show count of all the records in these tables on mouse hovering the corresponding div in UI(It is an asp.net website). Please note the count may change in every minute or in hour. (Means new records can be added or deleted from the table [using another application]). Now the issue is like, it is taking lot of time to get the count (since it has lots of data). So each mouse over, it is having a call to corresponding database and taking the count. Is there any better approach to implement this?
I am thinking of implementing something like as below.
http://www.worldometers.info/world-population/
But to change the figures like that in each second I need to have a call to the database. Right? (To get the latest count) Is there any better approach to show data like this statistics?
By the Way, I am using MySQL.
Thanks
You need to give more details - what table engines you are using, how does your count query look like, etc.
But assuming that you are using InnoDB, and you are trying to run count(*) or count(primary_id_column), you have to remember that InnoDB has clustered primary keys, that are stored with the data pages of the row itself, not in separate index pages, so the count will do full scan on the rows.
One thing you can try is to create additional, separate, not primary index on any unique column (like row's id etc,) and make sure (use explain query statement) that your count uses this index.
If this does not work for you, I would suggest to create separate table (for example with columns: table_name, row_count) to store counters in it and create triggers on insert and on delete on other tables (you need to count records in) to increment or decrement these values. From my experience (we monitor number of records in daily and hourly manners, on tables with hundreds of milions of records and heavy write load: ~150 inserts/sec) this is the best solution I have came up so far.
Suppose I have a table A, creating a view V from that table.
Then I do several queries from V. I wonder if V will be re-constructed each time I query? or it will be constructed only 1 time, and being saved somewhere in memory by DBMS for next queries (which I think similar to query from a table)?
In general, no. V is a transient set of rows that is computed when requested by a query. Because you can apply additional WHERE and ORDER BY criteria when querying from a view, the execution plan for two queries against the same view could conceivably be quite different. The database generally cannot reuse the results of a previous query against a view to satisfy the next query against that view.
That said, there is a relatively new technology in some engines called Materialized Views. I have never used them myself, but my understanding is that these views are pre-computed based on updates that are made to the underlying tables. So with Materialize Views you do get improved SELECT performance, but at the expense of decrease INSERT, UPDATE, and DELETE performance.
You should also be aware that multi-column indexes can be used to precompute certain selections and sort orders involving individual tables. If you issue a query against a table that can be satisfied using a compound index (only the columns in the index are required by the query, and the sort order matches the index) then the table itself need never be read, only the index.
Views in MySQL are not a de facto caching solution.
MySQL runs the query against the base tables every time you query a view on those base tables. The results of the query are not stored for the view.
As a result, there is no need to "refresh" the view as there is when using materialized views in Oracle Microsoft SQL Server. Even the SQL in a MySQL view definition is re-evaluated every time you query the view.
If you need something like materialized views in MySQL, one tool that might help is FlexViews. This stores the results of a query in an ordinary base table, and then monitors changes recorded in MySQL's binary log, applying relevant changes to the base table. This tool can be quite useful, but it has some caveats:
FlexViews is written in PHP, and as such it has some performance limitations. Depending on your write traffic load, FlexViews may not be able to keep up.
It doesn't support every possible type of SELECT query.
FlexViews-managed materialized view tables are not updateable. That is, you can UPDATE this view table, but the change will not apply to the base tables.
According to Pinal Dave, a view must be refreshed in order to reflect changes made to its referenced table(s). I'm not sure this makes a view of a simple 1-table query any more efficient than querying the table directly (it probably doesn't) but I think it means that views containing complex joins and subqueries may be more efficient than their non-view counterparts.
Pinal Dave has more to say about the other limitations of SQL views (or features, if you like). Maybe you can learn something useful there.
Mysql Views do not support Indexes. (as like in Oracle, where you can create index in Oracle Views) But mysql views can use the indexes in underlying table when created with Merge Algorithm.
If you have to use views, then adjust your JOIN BUFFER.
Using, Something like this
set global join_buffer_size=314572800;
Do profile the differences before and after changing the buffer size.
I have seen after increasing join buffers, the view query executes in same time (in ms) as the table of the same size will do.
Consider a table with a bit column indicating whether the object is active or inactive where the majority of the items are inactive (closed).
My understanding was that because of the limited number of distinct values for this column (2), the SQL Engine found it more efficient to perform a table scan to find the open items rather than attempt to index over a bit column.
SQL 2008 has a new feature that allows filters on an index. Without know much about the internals of it, I would assume that the index contains a reference to a record only if it meets the filter criteria and that this approach would provide an efficient means of retrieving all of the active records without having to resort to splitting the active records into separate tables or partitions.
I used to place the primary key of the open records records into a table that I used to identify the active records and then joining the main table to this "active list" table to return only the active records.
Is there any reason why using a filtered index for this purpose would not be appropriate in this situation?
A filtered index on an Active bit field is a valid choice.
You will probably want to add a specific UPDATE STATISTICS for
filtered indexes (especially on volatile data) that specifically
updates their stats with a FULLSCAN. The good news is that they are
likely to be smaller indexes (and therefore easier/less-costly
statistics to update)
This is because the update statistics threshold is based on the underlying column rather than the filtered index values only.
Ref.