$ PERL5LIB=/path perl script.pl
or
use lib '/path';

Thanks

$VAR1 = {
          'a' => 'b',
          'e' => 'f',
          'c' => 'd',
          'g' => 'i',
          'j' => undef
        };

Вот тебе ещё вариант: https://perlbanjo.com/6642853d21

Спасибо. Это модифицированный вариант https://t.me/usePerlOrDie/36671
Надо уже найти время протестировать все варианты и выбрать самый быстрый.

@PerlBanjoBot $ perl -MData::Dumper -e 'print Dumper { "a=b c=d e=f g = =x i=j" =~ /(?:^|\s)([^=[:space:]])?(?:=(\S+))?/g }'

$VAR1 = {
         'a' => 'b',
         'i' => 'j',
         'c' => 'd',
         'g' => undef,
         'e' => 'f',
         '' => 'x'
       };
https://PerlBanjo.com/b1c1df37bd

Вот так корректнее

А длину массива после split можно так пофиксить (без push и арифметики):

perl -MData::Dumper -e '@a = split "foo", 2; print Dumper \@a; $#a = 1; print Dumper \@a'
$VAR1 = [
          '2'
        ];
$VAR1 = [
          '2',
          undef
        ];

ребят подскажите, вопрос хоть не связаный с perl но всё же думаю кто нибудь да и сталкивался.
имеется база mysql и когда происходит выборка, нагружено одно ядро, а я понял что на каждый запрос это одни процесс, на каждый процесс одно ядро. но вопрос, как мне ускорить выполнение запроса? разбить сам запрос на n количество малых запросов и например тем же perl все сводить?

нет, только хуже сделаешь

собери статистику, добавь индекс (если требуется)

плохая статистика — плохой план запроса

Прогони explain и посмотри на чем тупит и как оптимизировать. Если у тебя там просто 100500 миллионов строк, то, возможно, стоит подумать про смену архитектуры

У него поля в разной последовательности

Любой dba скажет тебе, что лучше всего запрос делать на стороне дб, потому что она оптимизирует его и быстрее отработает, чем делить на части и сводить в приложении.
Но на самом деле, у тебя слишком общий вопрос. Надо детали

А еще убедись, что ты правильно используешь индексы. Там у mysql много нюансов, начиная с того, что используется максимум 1 индекс на JOIN/FROM

А вот это кстати (про "на стороне БД") - не так однозначно.
В high-load OLTP считается (в т.ч. по мнению DBA), что делать JOIN на стороне приложения лучше, т.к. экономит ресурсы СУБД. Ну и можно денормализовать хранение, унеся часть данных на другой сервер (и сэкономив таким образом IOPS). Разумеется, схемы должны быть оптимизированы для такого.

так это поди про микросервисы какие

Это немного чушь, но в одном месте только. СУБД потратит больше ресурсов если руками делать джоин. Ручной джоин оправдан только если часть ресурсов на другой базе. Эта тонкость важна.

Суммарная нагрузка на БД в условных попугаях да, больше. Но при джойне в приложении, во-первых, нет большой зависимости от планировщика запроса. Поэтому меньше вероятность того, что под нагрузкой сам запрос начнет выполняться существенно большее время (что при одинаковой нагрузке означает существенно бОльшую единовременную нагрузку на СУБД и накладные расходы). Во-вторых появляется гибкость в размещении связанных данных (например, для них можно реализовать другую стратегию шардирования, реплицировать по-другому и т.д). В пределе это все стремится к NoSQL и т.п.