Whats the equivalent of ST_DWithin (PostGIS - PostgreSQL) for MySQL? - mysql

I am trying to find an efficient way to do proximity queries, ie to return POINTs which are within a radius from a central POINT.
I understand that PostGIS's ST_DWithin method is a good way to do this in PostgreSQL and that it uses the INDEX.
I am currently using ST_Distance_Sphere(g1, g2 [, radius]) which returns the minimum spherical distance between Point on a sphere, in meters.
SELECT placeNames FROM myPlaces
WHERE ST_Distance_Sphere(placeLocation, POINT(28.861105, 77.337)) < 10000
I'm using the WHERE clause to filter the rows. Is the query using the index? If no, is there a better approach to implement the same.
I'm using MySQL 5.7.26 and 8.0.16, both running the default InnoDB database engine.


At this point in MySQL, there seems to be no 'more efficient' alternative to ST_Distance_Sphere or any other which uses a spatial index.


Firtly SRID set this query 4326 use it;
sample
SELECT ST_SetSRID(ST_MakePoint(-71.1043443253471, 42.3150676015829),4326);

Related

How can I add my own index algorithm to the MySQL source code?

I have implemented the inverted index algorithm and want to add it to the MySQL source code (I know InnoDB contains inverted index, but my own algorithm has other plans). When MySQL receives an execution statement like SELECT * FROM doc WHERE docContent LIKE '%keyWord%';, MySQL will use the inverted index algorithm implemented by myself instead of really using LIKE.
MYSQL version: 8.0.27

Is better POW() or POWER()?

I must make an exponentiation of a number and I don't know which function to use between POW() and POWER(). Which of the two functions is better?
Looking at the MySQL documentation I saw that they are synonymous, but I wanted to understand if there was a reason for two functions that do the same thing.

POWER is the synonym of POW. So nothing is better, it is the same:
POWER(X,Y)
This is a synonym for POW().
Using two different names for the same function gives you the possibility to port an SQL query from one dialect to an other dialect without (big) changes.
An example:
You want to use the following TSQL query on MySQL too:
SELECT POWER(2,2) -- 4
Now you can write these query specific for the dialects:
SELECT POWER(2,2) -- 4 - TSQL (POW is not available on TSQL)
SELECT POW(2,2) -- 4 - MySQL
But you can also use the POWER function on MySQL since this is a synonym for POW:
SELECT POWER(2,2) -- 4 - TSQL and MySQL

pow and power are synonyms in MySQL.
I'd use power since it's part of the ANSI SQL standard and using it would make your code easier to port if you ever decide to use a different database.

hibernate and mysql partitioning

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

Mysql Spatial extension

So i have these records in my db with lat/long. I'd like to be able to query for records that are near some specific a lat/long. So I started to look around for a solution for that and it seem to point to use mysql spatial extension.
Reading this documentation http://dev.mysql.com/doc/refman/5.0/en/mysql-spatial-datatypes.html
Is a Point correspond to lat/long? If it's not, what is it? and how do i convert it to a Point?

A Point in MySQL is a lat/long pair. I would suggest looking at this first:
http://janmatuschek.de/LatitudeLongitudeBoundingCoordinates

How do you write a case insensitive query for both MySQL and Postgres?

I'm running a MySQL database locally for development, but deploying to Heroku which uses Postgres. Heroku handles almost everything, but my case-insensitive Like statements become case sensitive. I could use iLike statements, but my local MySQL database can't handle that.
What is the best way to write a case insensitive query that is compatible with both MySQL and Postgres? Or do I need to write separate Like and iLike statements depending on the DB my app is talking to?

The moral of this story is: Don't use a different software stack for development and production. Never.
You'll just end up with bugs which you can't reproduce in dev; your testing will be worthless. Just don't do it.
Using a different database engine is out of the question - there will be FAR more cases where it behaves differently than just LIKE (also, have you checked the collations in use by the databases? Are they identical in EVERY CASE? If not, you can forget ORDER BY on varchar columns working the same)

select * from foo where upper(bar) = upper(?);
If you set the parameter to upper case in the caller, you can avoid the second function call.

Use Arel:
Author.where(Author.arel_table[:name].matches("%foo%"))
matches will use the ILIKE operator for Postgres, and LIKE for everything else.

In postgres, you can do this:
SELECT whatever FROM mytable WHERE something ILIKE 'match this';
I'm not sure if there is an equivalent for MySQL but you can always do this which is a bit ugly but should work in both MySQL and postgres:
SELECT whatever FROM mytable WHERE UPPER(something) = UPPER('match this');

There are several answers, none of which are very satisfactory.
LOWER(bar) = LOWER(?) will work on MySQL and Postgres, but is likely to perform terribly on MySQL: MySQL won't use its indexes because of the LOWER function. On Postgres you can add a functional index (on LOWER(bar)) but MySQL doesn't support this.
MySQL will (unless you have set a case-sensitive collation) do case-insensitive matching automatically, and use its indexes. (bar = ?).
From your code outside the database, maintain bar and bar_lower fields, where bar_lower contains the result of lower(bar). (This may be possible using database triggers, also). (See a discussion of this solution on Drupal). This is clumsy but does at least run the same way on pretty much every database.

REGEXP is case insensitive (unless used with BINARY), and can be used, like so...
SELECT id FROM person WHERE name REGEXP 'john';
...to match 'John', 'JOHN', 'john', etc.

If you're using PostgreSQL 8.4 you can use the citext module to create case insensitive text fields.

use COLLATE.
http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html

You might also consider checking out the searchlogic plugin, which does the LIKE/ILIKE switch for you.

You can also use ~* in postgres if you want to match a substring within a block. ~ matches case-sensitive substring, ~* case insensitive substring. Its a slow operation, but might I find it useful for searches.
Select * from table where column ~* 'UnEvEn TeXt';
Select * from table where column ~ 'Uneven text';
Both would hit on "Some Uneven text here"
Only the former would hit on "Some UNEVEN TEXT here"

Converting to upper is best as it covers compatible syntax for the 3 most-used Rails database backends. PostgreSQL, MySQL and SQLite all support this syntax. It has the (minor) drawback that you have to uppercase your search string in your application or in your conditions string, making it a bit uglier, but I think the compatibility you gain makes it worthwile.
Both MySQL and SQLite3 have a case-insensitive LIKE operator. Only PostgreSQL has a case-sensitive LIKE operator and a PostgreSQL-specific (per the manual) ILIKE operator for case-insensitive searches. You might specify ILIKE insead of LIKE in your conditions on the Rails application, but be aware that the application will cease to work under MySQL or SQLite.
A third option might be to check which database engine you're using and modify the search string accordingly. This might be better done by hacking into / monkeypatching ActiveRecord's connection adapters and have the PostgreSQL adapter modify the query string to substitute "LIKE" for "ILIKE" prior to query execution. This solution is however the most convoluted and in light of easier ways like uppercasing both terms, I think this is not worh the effort (although you'd get plenty of brownie points for doing it this way).