My app uses spring+hibernate+mysql.
Some of my tables are growing very big and horizontal partitioning would really benefit me in solving related performance issues.
I took a look at hibernate shards but didn't like the fact that it is not on the maven repo and that it is still labeled "beta".
I'm considering using mysql partitioning feature and have some questions:
If I create partitions using mysql can I keep using my app as usual without any errors from hibernate?
I understand I cannot explicitly tell hibernate which mysql partition to use. But if I use hibernate filters to "suggest" what partition to aim to will mysql optimize the query and use the right partition?
Example:
Say i partition my table by a column type that can be 1,2,3,4 - each type goes to a different partition.
If i add a hibernate filter on this type column so the final query will be someting like:
Select blabla from mytable where stuff AND type=3 (the hibernate filter added the type = 3).
Will mysql pick this up and treat it the same as
Select blabla from mytable PARTITION (type3) where stuff
While #YaK is correct about the location of the data, the MYSQL SELECT statement in 5.6 DOES allow you to specify the Partition as #samz questioned, for performance reasons. See http://dev.mysql.com/doc/refman/5.6/en/partitioning-selection.html.
MySQL does all the dirty work related to finding which partition the data may be/will be stored. Whether the table is paritionned or not is fully transparent from the client point of view, the queries remain unchanged. There is no such thing as SELECT col FROM mytable PARTITION(p); with MySQL.
[edit] As pointed out by TJChambers, SELECT col FROM mytable PARTITION(p); does exist as of v5.6, and allows for explicit, manual partition pruning.
Hey Can we use here session.createsqlquery("Select blabla from mytable PARTITION (type3) where stuff "); to resolve the issue? Hibernate support native API after all.
Thanks
Sanjeev Yadav
Related
I have been trying to remove duplicates from the table but I need more of a generalized way of doing it. There are numerous ways to do it if the table has a unique identifier like row ID. But otherwise, it seems to be very difficult and different for different databases.
I even explored CTE (Common Table Expressions) to do the same but seems that databases do not allow the use of CTE followed by DELETE clause (at least what I saw with MySQL and Snowflake).
But in PostgreSQL, there seems to be a way in which we can achieve this without necessarily having any unique identifier. This is through the use of ctid, a system column in PostgreSQL. I am curious if there is a similar functionality like ctid for other databases especially MySQL and Snowflake is what I am interested in currently.
I am curious if there is a similar functionality like ctid for other databases especially MySQL and Snowflake is what I am interested in currently.
There is no CTID in Snowflake.
SQL Server: Index columns used in like?
I've tried using the query method in the link above with Postgres (0.3ms improvement), it seems to only work with MySQL (10x faster).
MYSQL
User Load (0.4ms) SELECT * FROM users WHERE reverse_name LIKE REVERSE('%Anderson PhD')
User Load (5.8ms) SELECT * FROM users WHERE name LIKE ('%Anderson Phd')
POSTGRES
User Load (2.1ms) SELECT * FROM users WHERE reverse_name LIKE REVERSE('%Scot Monahan')
User Load (2.5ms) SELECT * FROM users WHERE name LIKE '%Scot Monahan'
Did some googling but couldn't quite understand as I'm quite new to DBs. Could anyone explain why this is happening?
To support a prefix match in Postgres for character type columns you either need an index with a suitable operator class: text_pattern_ops for text etc. (Unless you work with the "C" locale ...)
Or you use a trigram index to support any pattern - then you don't need the "reverse" trick any more.
See:
PostgreSQL LIKE query performance variations
You'll see massive performance improvement for tables of none-trivial size, as soon as an index can be used for the query. Have a look at the query plan with EXPLAIN.
I work with Yii 1.1.13.
Is it good to call a table group? (In MySQL GROUP is a keyword, as used in "GROUP BY")
It's probably a bad idea, while some RDBMS support applying keywords to fields or tables (and accessing them using [] i.e select [group] from tbl ) it doesn't mean you should.
We recently have an issue where we had a field name group in one of our main tables, this was on a DB2 engine and we never had an issue, but then we moved our DataWarehouse to a PostgreSQL's fork named Greenplum and it didn't support a keyword as name for a field, so the DBA's were forced to change the field name in the migration and several services and reports failed until the code was changed. Production supported was impacted and everybody was mad/crazy about this.
It is my recommendation to avoid it, and remember anything that can go wrong, will go wrong
I am working in a project where we are using SQL Server database currently. But recently a decision has been taken that the database will be changed to MySQL.
I am not using any stored procedures, views, triggers, user defined functions, etc. But I think even then some queries written for SQL Server will not be supported by MySQL.
Can anyone help: what are the things that I have to check (and change) so that all the queries will work properly for MySQL also?
Queries that I know without consulting the documentation that will not work:
(recursive) common table expressions
windowing functions
queries using the standard SQL string concatenation ||
UPDATEs with JOIN are different between the two systems
Date arithmetics: date_column + 1 behaves differently in SQL Server
Division by zero will produce an error
SQL Server will reject values that do not fit into a column (instead of silently truncating it, which MySQL does in the default installation)
DDL that will not work and might have an impact on performance and/or data quality
datetime columns where you need precision up to milliseconds
tables with check constraints
indexed views
triggers on views
table functions (select * from my_function(42);)
filtered indexes ("partial index")
function based indexes
There's always the option to take commercial support from MySQL AB for this problem. I'm pretty sure they've done enough MSSQL->MySQL migrations to know alot about that. If a price tag on the migration is not a problem.
Alternatively, you could try to run the MySQL Migration Toolkit over the data and look for meaningful error messages at the stuff it cannot migrate. MySQL Migration Toolkit is part of the MySQL GUI Tools.
What would be the equivalant in MySQL for:
Saving a command for later reuse.
eg: alias command1='select count(*) from sometable;'
Where then I simply type command 1 to get the count for SomeTable.
Saving just a string, or rather part of a command.
eg: select * from sometable where $complex_where_logic$ order by attr1 desc;
WHere $complex_where_logic$ is something I wish to save and not have to keep writing out
Another approach is to create a view with your $complex_where_logic$ and query the view instead of the tables:
CREATE VIEW my_view AS SELECT * FROM sometable WHERE $complex_where_logic$
SELECT my_column FROM my_view ORDER BY some_column
Whenever you query a view, you always get the up-to-date data. Internally, MySQL runs the SELECT given in the CREATE VIEW statement and queries the results in order to obtain the results of your current SELECT. Therefore, a view does not improve performance compared to a single query. There a two main advantages in using views:
you have simpler SELECT statements since you do not have to type complex WHERE or JOIN Syntax again and again
you can use it to control user privileges, e.g. give a user access to a view but not to the original tables; this is not useful in your example, but - for example - you can think of views containing aggregate data only
This "template" feature could be part of client tools. Basically I use Toad. It has record macros feature. I think it is possible to do.
I take it the answer you are looking for isn't 'stored procedures'...?
I found that the best solution for this is just any rich GUI for SQL queries (TOAD, mysql query browser, etc). They offer the ability to save commands and browse them and well, of course, much more.