MySQL VIEW vs. embedded query, which one is faster? - sql

I'm going to optimize a MySQL embedded query with a view, but I'm not sure whether it will give an effect:
SELECT id FROM (SELECT * FROM t);
I want to convert it to:
CREATE VIEW v AS SELECT * FROM t;
SELECT id FROM v;
I've heard about "indexed views" in SQL Server, but I'm not sure about MySQL. Any help would be appreciated. Thanks!

Indexed views in SQL Server are generally called "materialized views", which MySQL does not support. MySQL's VIEW support is rather limited in comparison to other vendors - the restrictions are listed in their documentation.
A normal view is merely a prepared SQL statement - there's no difference between using the two examples you provided. In some cases, the WHERE clause when selecting from a View can be pushed into the VIEW query by the optimizer, but it's completely out of your control.

The view might be faster (it probably is), but why don't you just test it? Or run an EXPLAIN against both queries to see how they will execute?

It's about the same. Will it be fast or not it depends on your indexes.
MySQL caches query results, so as long as your queries are same between executions, and as long as underlying dataset is same (no new records added), it will return cached results on next query execution.

The select statement will be run each time you fetch a view.
A view behaves a bit differently, see Create View

Related

Teradata -execute "SHOW SELECT FROM" in a stored procedure or etl alternative

I am trying to do a call to Teradata with a list of views of which I want to know the tables.
So I built a loop in an etl tool to execute "SHOW QUALIFIED SELECT * FROM ..." on all of them.
However, this seems to be unsupported and the teradata documentation suggests this too (any form of SHOW is not supported in stored procedures).
Could you think of another way to get the underlying tables in a view?
thank you
Update: FYI SHOW SELECT * FROM ... is different from SHOW VIEW
in that it also shows -ALL- underlying tables involved, e.g. in case of views on views.
Alternate call for the SHOW VIEW:
select createText from dbc.tvm t1 join dbc.dbase t2 on (t1.databaseId=t2.databaseId)
where TVMName = '<your_view_name>'
and databaseNameI = '<your_db_name>'
;

Oracle SQL Query COST is coming more when its fired on view

I am using view to fire SQL query in Oracle. Where condition contains column on which index is already created but still its running slow. If i replace the view code directly in query than result is fast. Using Explain plan i figured out when query is fired on View filter predicate is created but when it is run directly no such predicate is created which is hampering the performance severely. Any help or link will be appreciated. I am using Oracle 11 g database?
Select * from View1 where col1='xyz' (very slow)
select * from (Full query of View) where col1='xyz'(very fast)
On col1 index is created

SQL Performance: LIKE vs IN

In my logging database I have serveral qualifiers specifying the logged action. A few of them are built like 'Item.Action' e.g. 'Customer.Add'. I wonder which approach will be faster if I want to get all logging items that starts with 'Customer.':
SELECT * FROM log WHERE action LIKE 'Customer.%'
or
SELECT * FROM log WHERE action IN ('Customer.Add', 'Customer.Delete', 'Customer.Update', 'Customer.Export', 'Customer.Import')
I use PostgreSql.
Depends on indexes on log table. Most likely - queries will have the same performance. To check - use explain or explain analyze. Queries with the same execution plan (output of explain) will have the same performance.

Where is the table/view script generated and how to get it?

Say I have written a Create Table script in a query window and run it. So the table got created. Now, where is this script file being generated (system table). I mean if I do a
select * from sys.syscomments
I will get the script for stored procedure or function in the "Text" column. Likewise any way of getting the same for table or view?
Any DMV etc...
Thanks in advance
I'm not sure where the script is stored, but if you're looking to be able to view the scripted language to create the table, in SQL2008 R2 (and I'm pretty sure SQL2008) SSMS can generate the script on the fly. Just select your Table (or View, SP, etc...) and right click. From the context menu, choose Script Table as Create To (or whatever other modification you choose from the list). Then you have a choice of output locations-the New Query Editor Window is probably easiest to see your results. From there you have the base language for that table's creation and you can modify or save it from there.
below query is also works for views
select * from sys.syscomments
For getting script of tables , you have to
Right Click on database >> tasks >> Generate Scripts >> choose objects (select tables)
I think that is the possible way of getting table scripts.
For views you can use the column VIEW_DEFINITION in:
SELECT *
FROM INFORMATION_SCHEMA.VIEWS
I don't think there is an equivalent for tables because tables don't require a stored definition because the table itself is the definition. If you need to copy table structures then the best method is probably to use:
SELECT *
INTO NewTable
FROM OldTable
WHERE 0 = 1
You could try generating your own scripts using the system views and creating dynamic SQL, something like this would get you started
This does not create constraints, and there maybe things I've missed, or cause it to break but the general gist is there. You could also do this outside of SQL as demonstrated quite nicely In this Answer.
HOWEVER I should add I do not condone the use of these methods. There are few scenarios I can think of where it would be necessary to programatically copy a tables structure in this fashion. If it is necessary to copy structures as a one off you'd be better off doing this using the generate script functions that are built into SSMS.

PL/SQL Developer - ignore/limit large data in queries

In PL/SQL Developer v7.1.x, is there way way to ignore large data types in queries or the "Query Data" feature. For example: If you right click on table FOO, and select "Query Data" this will execute a SELECT * FROM FOO. If that table contains BLOB data the query will take a while to complete and temporarily lock up the application. This is especially problematic when querying remote databases (for obvious reasons).
I would like a way to tell PL/SQL Developer not to retrieve large data by default. I know there is a way to limit the ResultSet size but this doesn't do what I am looking for.
I could just select each column I wanted ignoring certain ones but then I couldn't use the "Query Data" feature.
Thanks.
No, the Query Data feature does one thing and one thing only - queries all the data.
What you might find useful is that you can drag the name of a table or view from the Browser into a SQL Window, choose "Select" from the menu that pops up, and it will generate a SELECT statement on the table with all the column names included - but does not execute the query straight away. You can then edit it however you like (e.g. comment out the LOB columns) before you run it.
I know that Toad has something like that built in, but I'm not aware of a PL/SQL Developer option that disables BLOBS.
The option you are left with, for now, is to simply select all the columns individually and truncate the blob.
ie:
select foo, bar, trunc(baz,100) from foo where ...
Create a View that doesn't contain the blob column or whatever columns you don't routinely want to look at.