Run the following command to check all available versions of PHP:
# plesk bin php_handler --listThen, choose the binary (including path) from the column php-cli , for example:
php-cli:
/opt/plesk/php/7.1/bin/php
Note: Use the full path to launch binary in the command-line interface.Here is simple example oh how to install symfony4 using composer:
/opt/plesk/php/7.1/bin/php /usr/local/bin/composer.phar create-project symfony/skeleton my_project
PDO::exec to issue one-off non-prepared statements that don’t return result sets.PDO::query to issue one-off non-prepared statements that return result sets.Both of these are useful if the statements are only executed one time and/or if they are constructed dynamically in a way that is not supported by prepared statements. Usually requires additional tooling to properly construct statements (and avoid things like SQL injection vulnerabilities). That coupled to the fact their flexibility is seldom needed means that it’s often preferred to:
PDOStatement::prepare and PDOStatement::execute to prepare statements and execute them, regardless of whether they return results or not. Useful if executed multiple times and/or in a hot path. Also doesn’t require additional tooling to handle statement construction. Almost always recommended whenever possible.As of MySQL 5.7.7, this is what the documentation recommends for Red Hat Enterprise Linux 7, Oracle Linux 7, CentOS 7, SUSE Linux Enterprise Server 12, Fedora 24 and 25:
https://dev.mysql.com/doc/refman/5.7/en/using-systemd.html
On Ubuntu 16.04 the service is called mysql, not mysqld, so this is what I did:
sudo mkdir /etc/systemd/system/mysql.service.d
sudo vi /etc/systemd/system/mysql.service.d/override.conf
Added this in the new file override.conf:
[Service]
LimitNOFILE=1024 4096
Then restarted the service:
sudo systemctl daemon-reload
sudo systemctl restart mysql
and test it with
cat /proc/$(pgrep mysql)/limits | grep files
pkill -f index.php
Imagine you need to execute one ore more queries on a big size table, containing the history of the sales of an e-commerce point.
If your hardware resources are limited, scanning the whole table could require several minutes, and this in turn could imply long table locks and waste of time to the users.
Since version 5.1, MySql supports partitioning, a mechanism allowing data to be divided according to access needs.
There are several partitioning types. The most popular mechanisms are:
– RANGE: rows are divided based upon a specified column range
– HASH: the column hash is calculated based upon the record position in the partition resulting from the operation
– LIST: works like RANGE but the values are not surely adjacent
The partitioning of a table works in two different manners:
– during the table creation
CREATE TABLE sales (
id int NOT NULL,
order_date DATETIME NOT NULL,
user bigint NOT NULL,
total float NOT NULL DEFAULT '0',
receipt_id bigint NULL
) ENGINE=InnoDB PARTITION BY RANGE(YEAR(order_date)) (
PARTITION p_history VALUES LESS THAN (2014),
PARTITION p_data VALUES LESS THAN MAXVALUE
);during the modification of the table structure
ALTER TABLE sales PARTITION BY RANGE(YEAR(order_date)) (
PARTITION p_history VALUES LESS THAN (2014),
PARTITION p_data VALUES LESS THAN MAXVALUE
);An important tool for debugging the extraction operations is the following command
EXPLAIN PARTITIONS;
The command output shows the partition used by MySql for execution of the specified query.
The partitioning is a very effective tool, but it may give no results, if you don’t choose the proper partitioning strategy: partitioning a sales table according to the creation date and then filtering data based on users, might be useless, independently on the partition criteria, or could even worst the situation.